Hmmm - I originally didn't want to take part in that discussion, but we are seeing more and more "Vulnerabilities" reported about sensitive Information in Files not being obscured by some "crypto". Let's start out with the latest comments: > What could help our users is a default simple encryption of the Tax files. No. "default simple encryption" means it can be broken with a "default simple algorithm". Encryption without a key is useless. As is encryption without a sufficiently well picked key. If you can retrieve the file, brute force is always possible, so nothing but really _strong_ encryption using _strong_ keys will help. And I doubt any user that is as careless as having unprotected shares or opening C:\ to a filesharing network would take more care when picking passwords for all those potentially sensitive files out there. > Because not everyone using today's computers can utilized EFS or a third > party encryption tool. Putting some trivial encryption code into each and every application will not help. It will rather obscure the problem. Anyone with a little clue about reverse-engineering will be able to break it. And it will almost always be a BORE-scenario. So what is the problem, and what can be done to fix it? The problem is storage of sensitive information in files that are accessible to third parties. How can we fix it? 1) Remove third party access to the files! ======================================= This is IMHO the most important step, due to the weaknesses in the other methods I will detail below. If this is done properly, the whole "problem" disappears. But this includes that we have to try to make sure that software gets written in a responsible way, discouraging or even disallowing dangerous settings, warning the user in a way that really catches his attention (i.e. _NOT_ a "Press OK, if you want to do that stupid thing", but rather "Enter 'I know this is stupid.' in the Textbox below.") when he is doing something dumb and provide the software with adequate updates and patches as need arises. Yeah - a lot of work, but that will eliminate the problem. However we have to be realistic: This will not happen in the near future. Especially as many users seem to have a fancy for lots of more or less useless applications of ... well ... unknown quality. Now for the workarounds: 2) If 1) cannot be done for some reason, use _strong_ encryption to _encrypt_ the data. XORing them with "wrdlbrmft" will just make an attacker laugh, assuming he is just a bit smarter than a piece of wood. Never just obfuscate the passwords by using a generic key. Even if the app picks one individual key at installation time, it has to be stored somewhere and when you can retrieve the file, chances are, that you can as well retrieve the stored key. Note that when picking an encryption algorithm, you should be aware, that for such applications it should be very resistant to known plaintext attacks, as you will often be able to retrieve parts of the plaintext (like the name of the user) from other files you got from the system. In some cases it might be as well possible to mount chosen plaintext or maybe even chosen ciphertext attacks. 3) Strong encryption needs strong passwords. Make sure the user picks a strong one. The typical user won't do so by himself, as the success of worms guessing share passwords shows. Either get on the nerves of the user rejecting too simple passwords, or rather have strong passwords picked for the user, e.g. by using smartcards or similar. 4) If for some reason encryption cannot be used (say due to laws), make the user _AWARE_ that he is storing sensitive data to a file and that he should take Measures to protect it. What we IMHO should _not_ do, is encourage obfuscation of data with weak algorithms or generic keys fed to strong algorithms. That's like just putting a nice blanket over the problem and hoping no one will look beneath it. IMHIO obfuscating data serves only one purpose: Not giving away Information to someone _briefly_ _viewing_ over the file. That's o.k. to keep the sysadmin from the temptation to hit a user that picks a weak or offensive password with a wet haddock. It's as well o.k. to guard a password against a coworker that happened to look over your shoulder when you opened the wrong file. But it is NOT o.k., if an attacker can retrieve the file and play around with it all day. CU, Andy -- = Andreas Beck | Email : <becka@bedatec.de> =
