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
signature.asc
Description: Digital signature
