Re: MD5 authentication needs help

* Bruce Momjian (bruce@momjian.us) wrote:
> On Fri, Mar  6, 2015 at 07:02:36PM -0500, Stephen Frost wrote:
> > * Bruce Momjian (bruce@momjian.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.

> 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
then they will be slightly more susceptible to network-based sniffing
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.

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

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.
Thanks,
    Stephen