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



Relevant Pages

  • Re: Best practice for password hashing
    ... unless there is a database compromise. ... The most common scheme is never to store passwords, but to instead store a cryptographic hash of the password. ... That way, if the base machine is compromised, they can't guess very rapidly unless they can compromise both machines. ...
    (sci.crypt)
  • Re: Newbie - Is this Reasonable?
    ... because this hash is stored in the database. ... So you use PKCS5v2 to generate a key hash from a salt and the user's passphrase, then store the salt and the hash in a database. ... are even more critical in database applications because the payoff from tampering with selected fields may be much higher, fields tend to be fixed-length so it's easier to tamper with them in a meaningful way, and databases lend themselves to off-line analysis, so the attacker can marshall more resources and take more time to attack your system. ... You're using a stream cipher for encryption. ...
    (sci.crypt)
  • Re: looking for help with a counting algorithm
    ... >> subcategory is counted, the code goes back up the tree to the root, adding ... >> involve retrieving all the category memberships from the database, ... sub ReadCategories{ ... ReadCategories is called with two empty hash pointers by any of the ...
    (comp.lang.perl.misc)
  • Re: Best practice for password hashing
    ... c)Using a hidden salt or hidden basis value (that won't be revealed if the database is compromised because it exists outside the database) so that an attacker is missing a piece of the information required to calculate the hash at all. ... If the database is compromised, the attacker won't be able to make the mapping from password to hash at any cost, which renders compromise of the database irrelevant. ...
    (sci.crypt)
  • Re: Best practice for password hashing
    ... a)Making the hash expensive to calculate. ... database is compromised because it exists outside the database) so that an ... attacker is missing a piece of the information required to calculate the ... which renders compromise of the database irrelevant. ...
    (sci.crypt)