Date: Fri, 14 Mar 2003 22:44:20 +0100
From: Andreas Beck <becka@...atec.de>
To: bugtraq@...urityfocus.com
Subject: Obfuscating sensitive data? (was: response to tax software not encrypting tax info)


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@...atec.de>             =

Powered by blists - more mailing lists