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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +