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