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

Tom Lane wrote:
> "murphy pope" <pope_murphy@hotmail.com> writes:
> > But, if can peek at the server's user/password checksum (in the pg_pwd
> > file), I can connect to a server, get the server's salt, and combine it with
> > the stolen checksum, arriving at the checksum expected by the server.
>
> Hmm.  The double hashing scheme was supposed to prevent that attack,
> but looking at the code I think maybe it got implemented incorrectly.
> We should go back and look at the design discussions to see if this
> wasn't foreseen.

OK, let me explain how md5 works right now, and why it may not be
possible to fix the problem outlined above.

First, let's assume GUC 'password_encryption' is 'true'.  (I just set
this to default to true for 7.3, as agreed to months ago on the list.)

OK, user is created and stored in pg_shadow.  The user-supplied password
is MD5 encrypted and stored in pg_shadow.

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.

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.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026