Re: Secure Password in database

From: Chris Coakley (chris.coakley@isera.com)
Date: 09/01/01


Message-ID: <00ba01c13273$2a310cd0$0464a8c0@Atlas>
From: "Chris Coakley" <chris.coakley@isera.com>
To: "Rajkumar S." <listuser@myrealbox.com>, <secprog@securityfocus.com>
Subject: Re: Secure Password in database
Date: Fri, 31 Aug 2001 16:17:55 -0700

From: "Rajkumar S." <listuser@myrealbox.com>

> I am working on a web site user authentication. I store the and password
> in database as SHA hash. But that will enable some one to replace it with
> another hash if the database is compromised and thus effectively the
> password is changed. Is this the best that we can hope for? Or is their
> any better way? How do normally the password is stored?

Let me see if I can restate your problem as I have encountered it:
1. You want to verify a client login against a password.
2. You don't want to be able to compromise the client, so you use a one-way
hash on the password and validate a hashed login.
3. You want to verify that the hash currently stored has not been
compromised.

Ryan brings up a good point: if the database has been compromised, is there
anything else worth protecting?

In our case, the answer is yes

We've blowfish encrypted values in a database with the 2-way key being the
MD5 hash of ( the password concatenated with the MD5 hash of (the password))
(I nested this after trying to read this back to myself). This seems a
little silly, but now you can't even get the 2 way key without knowing the
user's password, which is not stored in the database (the MD5 hash of the
password IS stored in the database). Obviously, if the hash was changed, you
get a bunch of garbage back when you try to get the 2-way encrypted data. We
implemented this as a layer, and concatenated in our own secret strings so
that we could ensure that garbage was garbage. We've only used this on data
that was NOT needed for calculations. This method is fast enough for data
that just gets displayed (like personnel information such as Birthday,
social security number, credit card numbers, etc), but I wouldn't use it for
data used in calculations (purchase ammounts, money collected, etc).

If you don't encrypt your other data, this is moot because you've already
lost if the passwords have been changed.
If you don't use the password or it's hash in some other context, then you
really have no way of validating whether or not it has been changed (other
than resorting to obscurity).

BTW, the above system is only useful if only bob should have access to bob's
data. Nobody else (not even the dba) can view it. For us, that was a design
requirement.

Hope that helps,
Chris