On Wed, Mar 4, 2015 at 10:52:30AM -0500, Stephen Frost wrote: > 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).
What does storing multiple hash(password || stoarage_salt) values do for us that session_salt doesn't already do? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
