Re: MD5 authentication needs help

* Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> On Sat, Mar 7, 2015 at 01:56:51PM -0500, Stephen Frost wrote:
> > * Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> > > 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
>
> Yes, the second use would be a new authentication method.

Ok.. I don't think it's a good idea to try and base a new auth method
on what we're doing for md5, in any case. To the extent that we have
options as it relates to SCRAM or another reviewed authentication
protocol, perhaps it'd make sense to consider a per-cluster salt or
similar, but I'm not sure we actually want or need to do so.

> > 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.
>
> It would be a server-fixed salt sent to the client and applied before
> the session salt. The pg_authid value would also store with this salt.
> Again, I am brainstorming about poolers.

When it comes to poolers, I'm thinking we should be looking at an
approach to do an after-connection re-authentication. Essentially a
'SET ROLE WITH mypassword;' kind of approach, but also using a proper
protocol, etc. That way, the pooler wouldn't really need to worry about
the actual authentication of the user. This is also brainstorming, of
course, I don't have a fully formed idea about how this would work, but
I do know that some other RDBMS's offer a similar masquerade kind of
ability.

> > > 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.
>
> Oh, that is very interesting. It seems like you are basically applying
> my server-fixed salt idea, except you are doing it X times so sniffing
> and then replay is less of a problem. Hmmm. I am very glad there is
> no admin work --- I did not realize that. It does make the trade-off
> of your idea more appealing, though I still think it weakens MD5 in an
> unacceptable way.

Well, that's where I come down on the side of "our existing MD5 approach
is pretty darn weak wrt replay". I agree, we can fix that, but I was
comparing to what our MD5 approach currently provides.

> > > > 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.
>
> Uh, my calculations show that as 434 days of trying. (Not sure why you
> didn't bother doing that calculation.)

I did. I guess it wasn't clear but I was pointing out the difference
between my suggestion and the *current* state of things, where we have
the birthday problem.

> I think anyone who is worried
> about that level of attack would already be using MD5. Again, MD5 is
> mostly used in low-security settings where you just don't want the
> password sent over the wire in cleartext. Frankly, without TLS, you are
> already sending your queries and data across in clear-text, and there
> are other attack vectors.

This suggestion does not send the cleartext password over the wire.

> Fine, but causing MD5 to be less secure doesn't warrant fixing it this
> way.

What I was getting at is that it's not much less secure than our current
MD5 implementation when it comes to replay attacks. Improving MD5 to be
more robust against replay attacks would be good, except that it doesn't
address the pg_authid-based risk. I wish there was a solution which
allowed us to have both but I don't see one, without a wireline protocol
change.

I'm really not wedded to my suggestion (which isn't even mine, as I
tried to get at earlier- it's one approach which was suggested by
someone from Openwall) and I agree that simply changing the way we
create the salt on the server side would greatly improve our MD5
implementation against replay attacks.

I think we both have a better idea of the solutions being discussed and
what the trade-offs are. I do feel that it'd be better to change MD5
and encourage TLS use than to improve on MD5 as is, but I can certainly
understand your viewpoint that it makes replay worse and therefore
doesn't address the concern for which the challenge/response was
implemented originally.

I guess I'm not quite sure where to go from here except to hope that
someone has a chance to work on a new authentication method soon.

Thanks,

Stephen