Re: MD5 authentication needs help - Mailing list pgsql-hackers

* Bruce Momjian (bruce@momjian.us) wrote:
> On Sat, Mar  7, 2015 at 12:49:15PM -0500, Stephen Frost wrote:
> > Ok, this is the incremented counter approach you brought up previously.
> > Using the term 'cluster-wide salt' confused me as I thought you were
> > referring to changing the on-disk format somehow with this.
>
> Yes, I used the term cluster-wide salt in two cases:  first,
> cluster-wide counter for the MD5 session salt improvement, and second,
> cluster-wide fixed salt to prevent pg_authid reuse, but to allow reuse
> if the cluster-wide fixed salt was set to match on two clusters, e.g.
> for pooling.

Ok, how, in the second case, is pg_authid reuse prevented unless we also
change the on-disk pg_authid format?  It doesn't matter if there's a
different counter used between different clusters, if the attacker has
what's in pg_authid then they can trivially add any salt we send them
during the challenge/response to the pg_authid value and send us the
response we expect.

> > > The big win for this idea is that it requires no client or admin
> > > changes, while your idea of using a new salt does.  My personal opinion
> > > is that the 32-bit counter idea improves MD5 replays, and that we are
> > > better off going with an entirely new authentication method to fix the
> > > pg_authid vulnerability.
> >
> > There's apparently some confusion here as my approach does not require
> > any client or admin changes either.  If users are not using TLS today
>
> Really?  From your previous email I see:
>
> > 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:
>
> How do you generate these X versions of password hashes without admin
> changes?  In fact, I am not even sure how the server would create these
> unless it had the raw passwords.

Ok, I've apparently not been clear enough with the proposal.  What we
are hashing is the *current value* of what's in pg_authid- which we've
already got on disk.  All we have to do is read the current on-disk
value, add a salt to it, and store it back on disk.  We'd want to store
more than one, as discussed, since otherwise the challenge/response is
utterly useless.

> > then they will be slightly more susceptible to network-based sniffing
>
> Slightly?  X versions as stored in pg_authid vs 16k or 4 billion?

Sadly, yes.  It's not a perfect test, but a simple:

time for a in `seq 1 1000`; do nc localhost 5432 < /dev/null; done

Gave me 9.15s, or ~0.00915s per connection on a single thread.  That
times 16k is 146s or about two and a half minutes.  Of course, I'm
comparing this against what we currently do since, well, that's what we
currently do.  Changing it to 4b would certainly improve that.  Of
course, using multiple threads, having multiple challenge/responses on
hand (due to listening for a while) or simply breaking the MD5 hash
(which we know isn't a terribly great hashing algorithm these days)
would change that.

> > attacks than they are today due to the replay issue, but they are
> > already at risk to a variety of other (arguably worse) attacks in that
> > case.  Further, we can at least tell users about those risks and provide
> > a way to address them.
>
> Right, but again, the user can choose to use TLS if they wish.  I think
> you are saying MD5 replay security is worthless without TLS, but I can
> assure you many users are happy with that.  The fact this issue rarely
> comes up is a testament to that, and in fact, until we documented
> exactly how MD5 worked, we got many more questions about MD5.  Perhaps
> we should document the pg_authid reuse risk.

We should certainly document the pg_authid reuse risk.  For my part, I
don't think it's that people are happy with that trade-off but rather
that they simply don't realize the risk is there because, basically, who
would ever do that?  I'm not aware of any other server application which
even offers an option to store the authentication token out on disk in a
format which can be trivially used to authenticate to the system
(excluding people who are storing cleartext passwords..).

I do feel that people who are worried about MD5 replay security who are
*not* using TLS have not considered their risks properly.  It is unclear
to me why anyone should feel safe from an attacker who is able to sniff
the network traffic thanks to our challenge/response protocol.

> > Further, we can provide a solution to the replay concern by encouraging
> > use of SSL/TLS.  We can not provide any solution to the pg_authid-based
> > risk with this approach (with the possible exception of recommending
> > password-based auth, though the poor salt used makes that less
> > effective than md5 with the suggestion I've outlined).
> >
> > The incremental counter approach implies not using the approach I've
> > outlined, which is fine, but it doesn't change the pg_authid risk, nor
> > does it help at all for TLS-using environments, and for users who are
> > not using TLS, it doesn't make them particularly more secure to
> > cleartext-password loss, connection hijacking, data loss, or anything
> > except replay attacks.  When it comes to risks, for my part at least, I
> > don't feel like the replay risk is the largest concern to an operator
> > who is not using TLS.
>
> Well, users have a tool kit of options and they can choose what they
> want.

Can they?

How are they able to prevent an attacker who has gained access to
pg_authid from logging in?  What if the attacker gained access to the
replica or an unencrypted backup?  I agree that a user can, and should,
do their best to secure the pg_authid file, but there are good reasons
why cleartext password or authentication tokens shouldn't be stored on
disk directly.
Thanks,
    Stephen