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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
