Re: MD5 authentication needs help

* Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> 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?

By storing a hash of the result of the challenge/response, we wouldn't
be susceptible to attacks where the user has gained access to the
contents of pg_authid because the values there would not be (directly)
useful for authentication. Today, an attacker can take what's in
pg_authid and directly use it to authenticate (which is what the
interwebs are complaining about).

We wouldn't want to do that for just a single value though because then
there wouldn't be any value to the challenge/response system (which is
intended to prevent replay attacks where the attacker has sniffed a
value from the network and then uses that value to authenticate
themselves).

The only way we can keep the session salt random without breaking the
wireline protocol is to keep the raw data necessary for authentication
in pg_authid (as we do now) since we'd need that information to recreate
the results of the random session salt+user-hash for comparison.

This is essentially a middle ground which maintains the existing
wireline protocol while changing what is in pg_authid to be something
that an attacker can't trivially use to authenticate. It is not a
proper solution as that requires changing the wireline protocol (or,
really, extending it with another auth method that's better).

Thanks,

Stephen