Re: MD5 authentication needs help

On Sat, Mar 7, 2015 at 12:49:15PM -0500, Stephen Frost wrote:
> * Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> > On Fri, Mar 6, 2015 at 07:02:36PM -0500, Stephen Frost wrote:
> > > * Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> > > > I think the best solution to this would be to introduce a per-cluster
> > > > salt that is used for every password hash. That way, you could not
> > > > replay a pg_authid hash on another server _unless_ you had manually
> > > > assigned the same cluster salt to both servers, or connection pooler.
> > >
> > > Wouldn't that break the wireline protocol, unless you used a fixed set
> > > of known challenges? Perhaps I'm not following what you mean by a
> > > cluster-wide salt here.
> >
> > Well, right now the server sends a random 32-bit number as session salt,
> > but due to the birthday problem, that can repeat in ~16k connection
> > attempts. If we use an incremented counter for each session, we spread
> > the salt evenly over the entire 32-bit key space, making replays much
> > more difficult, e.g. 4 billion.
>
> 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.

> > I don't think the client would ever know the number was different from
> > the random number we used to send.
>
> Agreed.
>
> > 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.

> then they will be slightly more susceptible to network-based sniffing

Slightly? X versions as stored in pg_authid vs 16k or 4 billion?

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

> > I think your argument is that if users are using TLS, there is no replay
> > problem and you want to focus on the pg_authid problem. I think fixing
> > the pg_authid problem inside MD5 is just too complex and we are better
> > off creating a new authentication method for that.
>
> There is no replay problem if users are using TLS, that's correct. I
> don't believe the approach I've outlined is particularly complex, but
> that's clearly a biased viewpoint.
>
> I certainly agree that we need to create a new authentication method to
> address these issues properly and would love to discuss that further
> rather than discuss the merits of these potential improvements to md5.
>
> > The bottom line is we promised MD5 to prevent replay, but not pg_authid
> > stealing, and if we can improve on what we promised, we should do that
> > and not hijack MD5 to fix a different problem, particularly because
> > fixing MD5 for pg_authid requires admin action.
>
> Perhaps I'm missing it, but the documentation in 19.3.2 for 9.4 mentions
> md5 being useful to address password "sniffing" risk but doesn't
> mention anything about replay or the pg_authid-based risk. Sniffing of
> the cleartext password is addressed with the approach I've outlined, but
> the replay risk is greater.

I assumed sniffing meant sniff to later replay, which is why we use the
random session salt. We document how it works so users can decide.

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

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

+ Everyone has their own god. +