On Wed, Mar 4, 2015 at 10:52 AM, Stephen Frost <sfr...@snowman.net> wrote: > 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).
So, the server can only authenticate the user with the salts it has stored, because those are the only salts for which it knows what the response should be? But then if somebody steels pg_authid, they'll have the answers to the exact same set of questions that the server knows how to ask. And on top of that, replay attacks become massively easier. Any value you pick for X is going to be many orders of magnitude smaller than 4 billion, and if it's not entirely trivial you'll also have a huge expansion of the size of a pg_authid row. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
