Re: MD5 authentication needs help - Mailing list pgsql-hackers

Bruce, all,

I've been discussing this with a few folks outside of the PG community
(Debian and Openwall people specifically) and a few interesting ideas
have come out of that which might be useful to discuss.

The first is a "don't break anything" approach which would move the
needle between "network data sensitivity" and "on-disk data sensitivity"
a bit back in the direction of making the network data more sensitive.

this approach looks like this: pre-determine and store the values (on a
per-user basis, so a new field in pg_authid or some hack on the existing
field) which will be sent to the client in the AuthenticationMD5Password
message.  Further, calculate a random salt to be used when storing data
in pg_authid.  Then, for however many variations we feel are necessary,
calculate and store, for each AuthenticationMD5Password value:

md5_challenge, hash(salt || response)

We wouldn't store 4 billion of these, of course, which means that the
challenge / response system becomes less effective on a per-user basis.
We could, however, store X number of these and provide a lock-out
mechanism (something users have asked after for a long time..) which
would make it likely that the account would be locked before the
attacker was able to gain access.  Further, an attacker with access to
the backend still wouldn't see the user's cleartext password, nor would
we store the cleartext password or a token in pg_authid which could be
directly used for authentication, and we don't break the wireline
protocol or existing installations (since we could detect that the
pg_authid entry has the old-style and simply 'upgrade' it).

That's probably the extent of what we could do to improve the current
'md5' approach without breaking the wireline protocol or existing stored
data.

A lot of discussion has been going on with SCRAM and SASL, which is all
great, but that means we end up with a dependency on SASL or we have to
reimplement SCRAM (which I've been thinking might not be a bad idea-
it's actually not that hard), but another suggestion was made which may
be worthwhile to consider- OpenSSL and GnuTLS both support TLS-SRP, the
RFC for which is here: http://www.ietf.org/rfc/rfc5054.txt.  We already
have OpenSSL and therefore this wouldn't create any new dependencies and
might be slightly simpler to implement.

Thoughts?
Thanks!
    Stephen