Re: MD5 authentication needs help - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: MD5 authentication needs help |
Date | |
Msg-id | 20150307182846.GJ12967@momjian.us Whole thread Raw |
In response to | Re: MD5 authentication needs help (Stephen Frost <sfrost@snowman.net>) |
Responses |
Re: MD5 authentication needs help
|
List | pgsql-hackers |
On Sat, Mar 7, 2015 at 12:49:15PM -0500, Stephen Frost wrote: > * Bruce Momjian (bruce@momjian.us) wrote: > > On Fri, Mar 6, 2015 at 07:02:36PM -0500, Stephen Frost wrote: > > > * Bruce Momjian (bruce@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. Yes, I used the term cluster-wide salt in two cases: first, cluster-wide counter for the MD5 session salt improvement, and second, cluster-wide fixed salt to prevent pg_authid reuse, but to allow reuse if the cluster-wide fixed salt was set to match on two clusters, e.g. for pooling. > > 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 Really? From your previous email I see: > this approach looks like this: pre-determine and store the values (on a > per-user basis, so a new field in pg_authid or some hack on the existing > field) which will be sent to the client in the AuthenticationMD5Password > message. Further, calculate a random salt to be used when storing data > in pg_authid. Then, for however many variations we feel are necessary, > calculate and store, for each AuthenticationMD5Password value: How do you generate these X versions of password hashes without admin changes? In fact, I am not even sure how the server would create these unless it had the raw passwords. > then they will be slightly more susceptible to network-based sniffing Slightly? X versions as stored in pg_authid vs 16k or 4 billion? > 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. Right, but again, the user can choose to use TLS if they wish. I think you are saying MD5 replay security is worthless without TLS, but I can assure you many users are happy with that. The fact this issue rarely comes up is a testament to that, and in fact, until we documented exactly how MD5 worked, we got many more questions about MD5. Perhaps we should document the pg_authid reuse risk. > > 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. I assumed sniffing meant sniff to later replay, which is why we use the random session salt. We document how it works so users can decide. > 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. Well, users have a tool kit of options and they can choose what they want. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
pgsql-hackers by date: