Re: Is md5 really more secure than crypt? - Mailing list pgsql-general

<snip>
> OK, user logs in.  The backend sends two salts to the client
> --- one is
> the salt used to store that user's password in pg_shadow, the
> second is
> a random salt (random for every connection request).  The client
> encrypts the user's password with the pg_shadow salt, then the random
> salt, and sends it back to the server.  The server takes the
> md5-encrypted pg_shadow password, encrypts with the same random salt
> used by the client, and compares that to what the clients sends.
>
> Now, the complaint is that if someone sees the pg_shadow
> password, they
> can replay after using the random salt in the client to log in as that
> user.  That is true.  I think the only value to encrypting passwords
> stored in pg_shadow is that they can't see the actual password, which
> may be used in other places by that person. People have
> complained about
> this case, so it is good we can prevent it.

This means that the only way a password can be compromized is to see the
password hash in pg_shadow, and the only thing it can be used for is
logging into postgres throught playback.  No plain-text password can be
obtained.  The only way to see the hash would be as the postgres user
which normally has no password (out of the box anyway), and therefore as
root first, in which case none of this much matters anyway.

The random salt prevents a packet sniffer from doing any good unless the
random salt is re-produced later and a hacker is lucky enough to have
gotten it on the connection he wants to crack.  Possible, but...  very
unlikely, unless a pattern can be established in the pseudo random salts
sent to the client.  I doubt that's very likely either.

Short of using SSL to encrypt the entire session (passwords and all), I
can't think of a way to make it any stronger.  It sounds pretty safe to
me.


-- Glen Parker
glenebob@nwlink.com



> However, why can't we prevent the playback?  With /etc/passwd, if
> someone sees the password entry in that file, it doesn't mean they can
> log in as that user.  Why can't we do that?
>
> Think of /bin/login.  It has a secure connection with the terminal
> (kernel character device driver), so it sends the password in
> the clear.
> We don't have a secure connection to the client, so we have
> to randomize
> what they send us.  This prevents playback by wire sniffers.  With
> /bin/login, they clearly don't prevent the playback vulnerability.  If
> you see the characters coming from the client to /bin/login, you can
> replay it to log in yourself.
>
> What would be great would be if we could store an MD5 of what
> the client
> should send us, like /bin/login does, but because we use random salt
> every time, I don't see any way to do this.  What they send us is
> randomized, so we can't store some encrypted version of it.
>
> Am I missing something?  I know there are smart people on
> this list who
> can tell me if my hunch is correct.