On Wed, Aug 12, 2015 at 4:37 PM, Stephen Frost <sfr...@snowman.net> wrote: >> Please don't conflate those two things. They are radically different >> in terms of the amount of upgrade pain that they cause. The first one >> would be completely insane. > > Thanks for the clarification. I had gotten the (apparently mistaken) > impression[1] that there was some consideration for a hard break from > one release to the next to move from md5 to SCRAM.
Gosh, no way. Sorry if I gave the contrary impression; that was certainly not my intention. As I said before, I have no reason to believe that MD5 is insecure in the way we are using it. Unless much better attacks are published, I don't really care if people are still using it 5 years from now, or even 10. I just want to give people an *option* to move away from it, because: (1) It's possible that better attacks may be published, and (2) Even if they aren't, some people don't want to use anything that says "MD5" on the tin. > Would be great to get comments on the other comments, specifically that > adding SCRAM's password verifier won't seriously change the security of > a user's account or password based on an attack vector where the > contents of pg_authid is compromised. I do agree with the general > concern that the additional complexity involved in supporting multiple > password verifiers may result in bugs, and likely security ones, but I > really expect the larger risk to be from the SCRAM implementation itself > than how we get data into and back out of our own catalogs. Yes, the SCRAM implementation could be buggy. But also, OpenSSL has repeatedly had security bugs that were due to forcing servers to downgrade to older protocols. I wouldn't like us to start growing similar vulnerabilities, where SCRAM would have been just fine but an attack that involves forcing a downgrade to MD5 is possible. I don't think you are quite correct about the scenario where pg_authid is compromised. Even if the hash stored there is functionally equivalent to the password itself as far as this instance of PostgreSQL is concerned, the same password may have been used for other services, so cracking it has a purpose. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
