Password redux (was:Re: [HACKERS] Updated TODO list)

Bruce Momjian wrote:
> 
> > > Doing the random salt over the wire would still be a problem.
> >
> > There is absolutely no technical problem with storing hashed passwords and
> > still sending salted hash over the wire. It was recently discussed in detail
> > in "Hashing passwords" thread in pgsql-hackers list.
> 
> But you are hashing it with a secret known by the database adminstrator,
> and someone knows any password, like their own, can guess the secret by
> looking at the hashed version, no?

If the algorithm used for Unix passwords is used, it shouldn't be a
problem, as the "secret" is the password itself, which the client uses
to encrypt a 64 bit block of zeros, then it encrypts the resulting
64-bits of cyphertext with the password -- this process is repeated
until the 64-bit block of zeros has been encrypted (usually with DES) 25
times, using the salt to randomize things inside the DES algorithm
itself -- DES hardware chips that don't know about salt can't deal with
it. The encrypted zeros are then sent down the wire and compared to the
stored "hash". 

Using this algorithm, the only thing that goes over the wire is the
salted 64-bit cyphertext -- whose plaintext is a 64-bit block of zeros.

So, the only commonality between the stored "passwords" is the 64-bit
block of zeros -- which is why dictionary attacks and brute force
methods have to be used.  Of course, you could always use another crypt
algorithm instead of DES.  However, the standard unix crypt() call is
exportable -- it's only 56-bits.  MD5 and RSA have been used by various
vendors to do the same job. 
As an administrator, while I know the plaintext of the hash (64-bit
block of zeros), and I have the salted cyphertext of the hash (13
characters, the first two of which are the salt), and I have the
algorithm -- but none of that helps me find out the secret used to
encrypt the plaintext.

This makes it as secure as the Unix password system itself -- which,
AFAIK, no one has ever been able to DIRECTLY extract the password for
the cyphertext (brute forcing the password doesn't count).

However, there is a security risk with doing the crypt() in the client
-- if I know someone else's hashed password, I can bypass the client's
crypt() call (by hacking the client), and get authentication without
ever knowing the user's password.  To solve this, you don't transmit the
final hash or the plaintext password from the client to the server --
you wrap the password transmittal in SSL (session keys and all that),
and the backend does the crypt() and compare.

To summarize -- to use hashed passwords in a client-server system in a
relatively secure fashion:
1.)    Use a one-way algorithm, like Unix crypt(), where a known plaintext
is heavily encrypted by the password;
2.)    The password is never sent from the client to the server in
plaintext form;
3.)    An SSL-like mechanism is used to encrypt the transmission of the
password to the backend, which does the crypt() and compares it against
the stored hash -- this prevents us from using a known hash attack with
a hacked client.

There are two layers to this security cake -- network, and database.


Lamar Owen
WGCR Internet Radio