On Wed, Aug 12, 2015 at 4:37 PM, Stephen Frost <sfrost@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
