Re: MD5 authentication needs help

On 03/04/2015 04:52 PM, Stephen Frost wrote:
> 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.

not sure we should depend on TLS-SRP - the libressl people removed the
support for SRP pretty early in the development process:
https://github.com/libressl/libressl/commit/f089354ca79035afce9ec649f54c18711a950ecd

Stefan