I have a winforms application that connects to a couple of databases. However, I would like my app to be used even when the user is not connected to the internet. I had been writing datasets to XML files locally and reading them in based on the user preference whether to download from the database or use a local data file.
DataSet.WriteXml(localPath)
As the application is improving, I would like to encrypt the XML file to prevent the user from looking inside (There is a bunch of data in there but the application selectively displays data based on access levels assigned to users). I looked into 'Rijndael Managed' and got a prototype working based on Encrypt/Decrypt Files in VB.NET. I have not been able to figure how to pass in a stream to cryptography classes without them ever being saved to the disk.
Right now, I save the xml file out of the Dataset to a temporary directory and construct a new stream and pass it in to CrypotoStream which then writes an encrypted file to the desired location.
I am looking for a solution to directly pass in the stream without ever writing it to the disk. Please suggest.
a better thing to use would be the EncryptedXml Class
EncryptedXml Class
Encryption can entail different approaches for cryptographic strength, key bases, etc. Follow the examples in the MSDN documentation. This is not a short implementation, but it works extremely well.
other alternatives
Write into a MemoryStream and use MemoryStream.ToArray();
to read the encrypted stream
Just use the CryptoStream to load the DataSet.
refer to this like to read/decrypt
Read/decrypt encrypted XML file and then process internally
Sounds like MemoryStream may be what you are looking for.
Related
I have an application, its Name and Logo can changed directly from a TXT and a PNG file in the same directory.
I want to give the user the ability to change the Logo and Text File from another application that does the following :
Takes the Logo.png , Name.txt file paths and the directory of my Software then encrypt these two files and put them in the Directory of the Software
In the other hand. The software will Decrypt these two files and write them to Hard Disk to temp directory then use them to display the name and the logo.
I searched for the simplest and easiest way to encrypt a file and i found :
From the MSDN :
File.Encrypt():
Encrypts a file so that only the account used to encrypt the file can decrypt it.
Could someone please tell me what does it mean "only the account used to encrypt a file can decrypt it"
What about encrypting the application from Computer1 by Application1 then the file will be decrypted by Computer2 in Application2
Will the encryption work correctly ?
Edit:The purpose why I need to encrypt these two files is to avoid users from directly change the Logo and the Name of Application from the directory
This will encrypt the file, but not as you expect - and almost certainly not such that it can be decrypted by another application/user on a different computer.
The Encrypt method basically just toggles a feature of the underlying NTFS driver to encrypt the specified file on the file system itself. The nice feature is that it (typically) provides seamless file encryption for the user, but it isn't really portable encryption. It is the same as opening the file properties, clicking the advanced button and selecting the "Encrypt" checkbox.
More information on the encrypting feature of NTFS can be be found here: http://technet.microsoft.com/en-us/library/bb457116.aspx
No. You should use a proper encryption method such as those in System.Security.Cryptography namespace. There is a stream implementation for this, too, called CryptoStream, which you may wrap a FileStream with for encrypting files with.
This is related to Windows' EFS.
You can try it from Windows Explorer by right-clicking on the file, Properties, Advanced, Encrypt contents. The file data is automatically decrypted/encrypted on the fly as your app accesses it. But if another user logs in the machine and copies the file it will appear encrypted since the encryption is based on a user token.
This is may or may not be what you want and that depends on your intended use of that feature. If you don't want the user to be able to modify the data outside your app it won't be enough.
how can we encrypt an executeable file using c# and make that encrypted file still executeable without using extra file for decryption?
mean the decryption methods shuold be inside file.
how can i write something like that with c# language?
thanks in adavance
Storing encrypted data on clients machine and having it decrypt automatically means that you will have to store decryption key on that machine as well. This means that you can't effectively protect data and provide it to user. Such encryption is only used to slow down user from tampering with the data as time is needed to recover decryption key and algorithm.
If you want to encrypt code of the executable itself, to prevent user from tampering with it, this is a very very complex topic. It's only matter of persistence and time. You will not get an answer to such question in one StackOverflow post. You'll have to study PE and .NET file formats, operating system internals regarding executable loader as well as mscor*.
If you need to store some data
choose some encryption algorithm and encrypt your data into a file (see this question)
add encrypted file to your c# project as embedded resourse
in runtime access this file (see this question) and decrypt it (already discussed in first point)
We have a process that has SQL Server Reporting Services create a pdf file via
ReportExecutionService.Render
from data in the database. Then we save the byte array that Render returns to the database. Later I get the byte array and do a
File.WriteAllBytes
to write it to disk before attaching it to an email and sending it. The problem I'm running into is that after writing the file to disk, it is corrupt somehow. I'm not sure what to look at, can anyone help?
Thanks
EDIT:
I can write the file from SSRS to disk before saving the byte array to the database and I can view that fine.
If you work with the byte[] returned by render, then things are fine, but if once you write that to the DB and read it back, you have problems, correct?
Why don't you compare the array written in to the DB with the one you retrieve to find the problem? Then start looking into your DB write and read routines, finally your DB storage.
I've done similar things without problems, such as taking the results of a Reporting Services call into a bytestream and attaching that directly to an email, both using a memorystream and an on-disk file. So the basics of this are sound and should work.
Not sure if this is your issue or not, but if the PDF file itself is corrupt you might want to look at how it's being written. If Windows Preview can view the PDF but Adobe cannot, it may have to do with the fact that Adobe is expecting %PDF in the first 1024 bytes of the file (otherwise it will consider it corrupt).
In a project I am doing I want to give users the option of 'securely' deleting a file - as in, overwriting it with random bits or 0's. Is there an easy-ish way of doing this in C#.NET? And how effective would it be?
You could invoke sysinternals SDelete to do this for you. This uses the defragmentation API to handle all those tricky edge cases.
Using the defragmentation API, SDelete
can determine precisely which clusters
on a disk are occupied by data
belonging to compressed, sparse and
encrypted files.
If you want to repackage that logic in a more convenient form, the API is described here.
You can't securely delete a file on a journaling filesystem. The only non-journaling system still in heavy use is fat32. On any other system, the only way to securely delete is to shred the entire hard drive.
EDIT
The reason secure delete doesn't work, is that that data used to overwrite a file might not be stored in the same location as the data it is overwriting.
It seems Microsoft does provide a secure delete tool, but it does not appear to be something that you can use as a drop in replacement.
The only good way to prevent deleted file recover, short of shredding the disk, would be to encrypt the file before it is written to disk.
It wouldn't be secure at all. Instead you may wish to look at alternative solutions like encryption.
One solution would be to encrypt the contents of the data file. A new key would be used each time the file is updated. When you want to "securely delete" the data simply "lose" the encryption key and delete the file. The file will still be on the disk physically but without the encryption key recovery would be impossible.
Here is more detailed explanation as to why "secure" overwrites of files is poor security:
Without a low level tool (outside of .net runtime) you have no access to the physical disk location. Take a filestream on NTFS, when you "open a file for write access" you have no guarantee that the "updated" copy (in this case random 101010 version) will be stored in the same place (thus overwriting the original file). In fact most of the time this is what happens:
1) File x.dat is stored starting at cluster 8493489
2) You open file x.dat for write access. What is returned to you by the OS is merely a pointer to the file stream abstracted by not just the OS but the underlying file system and device drivers (hardware RAID for example) and sometimes the physical disk itself (SSD). You update the contents of the file with random 1 & 0s and close the filestream.
3) The OS likely may (and likely will) write the new file to another cluster (say cluster 4384939). It will then merely update the MFT indicating file x is now stored at 4384939.
To the end user it looks like only one copy of the file exists and it now has random data in it however the original data still exists on the disk.
Instead you should consider encrypting the contents of the file with a different key each time file is saved. When the user wants the file "deleted" delete the key and file. The physical file may remain but without encryption key recovery would be impossible.
Gutmann erasing implementation
I'd first try simply to open the file and overwrite its contents as I would normally do it. Pretty trivial in C#, I won't even bother to write it. However I don't know how secure that would be. For one thing, I'm quite certain it would not work on flash drives and SSD's that use sophisticated algorithms to provide wear leveling. I don't know what would work there, perhaps it would need to be done on driver level, perhaps it would be impossible at all. On normal drives I just don't know what Windows would do. Perhaps it would retain old data as well.
Sorry to keep asking so many questions, but you guys always seem to be so nice and helpful...
I need to do some application that imports data from a file. For instance, user selects one file and the application imports some data to database.
But I've been thinking, and this kind of app leads to a problem of integrity and authenticity of files. If a user changes the file the application is not allowed to use that information. And if one file is not from a source well known, the application can't use that file.
How do I do this kind of thing?
P.S.: I'm using C#.NET
Authentication and integrity are provided by digital signatures.
Follow driis' advice if you control the file format.
Alternately, if the file is XML, use an XML Signature.
Using C#/.NET:
Sign XML Documents
Verify the Digital Signatures of XML Documents
If you can control the source file format, you can embed a digital signature. If you base the signature on a hash of the file contents, then you can be sure that the file comes from a trusted source, and that is has not been tampered with.
It depends on how strong you want this protection.
For example, you can have an xml file (for human readability) which has a hash node somewhere which contains the hash of the original file (+salt). This can be updated by the program, but the user can have a harder time figuring out what that key means. When the program opens the file, it calculates the hash and checks if it's the same as the one written in the file.
You can even take one step further and use digital signatures, but that's way more complicated.