Re: MD5 authentication needs help

On Sat, Mar 7, 2015 at 01:56:51PM -0500, Stephen Frost wrote:
> * Bruce Momjian (bruce(at)momjian(dot)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

Yes, the second use would be a new authentication method.

> 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.

> > > > 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.

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.

> > > 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 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.

> > > 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..).

Yes, good point.

> 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.

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

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +