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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
