* Bruce Momjian (br...@momjian.us) wrote: > On Thu, Mar 5, 2015 at 11:15:55AM -0500, Stephen Frost wrote: > > * Bruce Momjian (br...@momjian.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
Description: Digital signature