Re: MD5 authentication needs help

* Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> On Thu, Mar 5, 2015 at 11:15:55AM -0500, Stephen Frost wrote:
> > * Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> > > On Wed, Mar 4, 2015 at 05:56:25PM -0800, Josh Berkus wrote:
> > > > So, are we more worried about attackers getting a copy of pg_authid, or
> > > > sniffing the hash on the wire?
> > >
> > > Both. Stephen is more worried about pg_authid, but I am more worried
> > > about sniffing.
> >
> > I'm also worried about both, but if the admin is worried about sniffing
> > in their environment, they're much more likely to use TLS than to set up
> > client side certificates, kerberos, or some other strong auth mechanism,
> > simply because TLS is pretty darn easy to get working and distros set it
> > up for you by default.
>
> I think your view might be skewed. I think there many people who care
> about password security who don't care to do TLS.

I'm not quite sure that I follow what you mean about caring for
"password security".

I'll try to clarify by suggesting a few things that I think you might
mean and will respond to them. Please clarify if I've completely missed
what you're getting at here.

If the concern is database access due to an attacker who can sniff the
network data then the approach which I suggested would make things
materially worse for users who do not employ TLS. Once the attacker has
sniffed the network for a little while, they'll have one and likely more
challenge/responses which they could use to attempt to log in with. As
discussed, our existing challenge/response system is vulnerable to
network sniffing based replay attacks also.

If the concern is database access due to an attacker who can see the
on-disk data, then the current situation makes it trivial for the
attacker to log in, while the approach I've suggested would require the
attacker to reverse hash(salt+auth_token) (where auth_token here is
taken to represent what we currently store on disk; even with my
suggestion, the attacker would not need to reverse the
hash(username+password) to gain database access).

If the concern is about getting at the cleartext password, then I don't
believe things are materially worse with either approach assuming a
network-based sniff attack. Both require that the attacker reverse
hash(salt+hash(username+password)) where the salt and password are not
known.

If the concern is about getting the cleartext password as it resides on
disk or in backups, we are not in a good position today. While the
password is hash'd, the "salt" used is the username which the attacker
may know ahead of the compromise. The approach I am suggesting improves
that situation because it would bring it up to the same level of
difficulty as that of the network-based sniff attack: the attacker would
have to reverse hash(salt+hash(username+password)).

> Also, my suggestion to use a counter for the session salt, to reduce
> replay from 16k to 4 billion, has not received any comments, and it does
> not break the wire protocol. I feel that is an incremental improvement
> we should consider.

You are correct, that would improve the existing protocol regarding
database-access risk due to network-based sniffing attacks.
Unfortunately, it would not improve cleartext or database access
risk due to disk-based attacks.

> I think you are minimizing the downsize of your idea using X challenges
> instead of 16k challenges to get in. Again, if my idea is valid, it
> would be X challenges vs 4 billion challenges.

The reason I have not been as excited by this approach is that we
already have a solution for network-based sniffing attacks. As Josh
mentioned, there are users out there who even go to extraordinary
lengths to thwart network-based sniffing attacks by using stunnel with
pg_bouncer. On the flip side, while there are ways to protect backups
through encryption, many other vectors exist for disk-based attacks
which result in either database access or finding the cleartext
password with much less difficulty.

Further, this only improves the authentication handling and doesn't
improve our risk to other network-based attacks, including connection
hijacking, sniffing during password set/reset, data compromise as it's
sent across the wire, etc. Encouraging use of TLS addresses all of
those risks. I don't recall any complaints about these other
network-based attacks and I do believe that's because TLS is available.
Combined with the approach I've suggested, we would reduce the risk of
disk-based attacks to the extent we're able to without breaking the
protocol.

For my part, doing this, or going with my suggestion, or doing nothing
with md5, really doesn't move us forward very much, which frustrates me
greatly. I brought this suggestion to this list because it was
suggested to me as one change we could make that would reduce the risk
of disk-based attacks while trading that off for a higher risk on the
side of network-based attacks while not breaking the existing network
protocol. To make it very clear- it is not a solution but rather a poor
bandaid. What we really need is a new password based protocol which is
based on a future-proof, well designed protocol, such as SCRAM.

Thanks,

Stephen