Re: You're on SecurityFocus.com for the cleartext passwords. - Mailing list pgsql-hackers

Bruce Momjian <pgman@candle.pha.pa.us> writes:
>>>> The goal here was to make wire sniffing unproductive, and because the
>>>> server supplied the salt to be used by the client, you can't just
>>>> re-use a sniffed password you saw on the wire.

Good point.  Are we trying to make the password challenge proof against
wire sniffing?  I think that might be an unreasonable goal.  People who
are concerned about sniffing attacks ought to be using something like
SSL to encrypt the *entire* connection (and/or a better auth protocol
than passwords, in the first place...).  I repeat my prior comment that
the data in the database is likely to be just as valuable as the
password.

> Right now the client receives a random salt from the server, it uses
> that salt to crypt the password, then send that back for comparison with
> the clear-text password we store in the system.

> What if we:
>     store the password in pg_shadow like a unix-style password with salt
>     pass the random salt and the salt from pg_shadow to the client
>     client crypts the password twice through the routine:
>         once using the pg_shadow salt
>         another time using the random salt

> and passes that back to the server.  The server can use the pg_shadow
> copy of the password, use the random salt make a new version, and
> compare the result.

Use the random salt to make a new version of what, exactly?  If the
server doesn't have the cleartext password, it can't make a crypted
password that will correspond to any randomly chosen salt either.

> This has the huge advantage of not requiring any new crypting methods on
> the client.  It only requires the crypt to happen twice using two
> different salts.

A serious objection to both this and the MD5 proposal is that it'd
create a cross-version incompatibility between clients and servers.
We were just fending off complaints about 6.5-to-7.0 incompatibilities
that were considerably less serious than being unable to connect at all,
so how well do you think this'd go over?

I think we should try to stick to the current protocol: one salt sent
by the server, one crypted password sent back.  The costs of changing
the protocol will probably outweigh any real-world security gain.

We could get some of the benefits of a random salt if we were willing
to enlarge the pg_shadow entry a little bit.  Suppose that we allow
N different salt values to be sent by the server (crypt(3) only allows
4096 possible salts anyway, but I'm thinking N in the range of 100).
When a password is set, crypt the password with each of these and store
*all* the results in pg_shadow.  Then we have the right crypted password
available to compare to the client response, and an attacker still has
a relatively low probability of having sniffed the right password.

BTW, I hear "MD5" being chanted like a mantra, but someone will have
to explain to me what it does that avoids the sniffed-crypted-password
problem...
        regards, tom lane