Likes: 
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> =
Quote
