Re: MD5 authentication needs help

On Fri, Mar  6, 2015 at 07:00:10PM -0500, Stephen Frost wrote:
> > > 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.

Yes, I am worried about that attack vector.  We have always been open
that MD5 only prevents password sniffing, though the 16k reply idea has
put a dent into that promise.

See the email I just sent on how I think we should proceed, i.e. by
creating a new authentication method to fix pg_authid stealing, and use
a salt counter to improve MD5.

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

Agreed.

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

Agreed.  Again, TLS has its own value beyond simple authentication.  I
just don't think getting MD5 to try to fix the pg_authid problem is the
right approach.

> 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

Agreed.

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

Again, agreed.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +