Re: WIP: SCRAM authentication - Mailing list pgsql-hackers
From | Stephen Frost |
---|---|
Subject | Re: WIP: SCRAM authentication |
Date | |
Msg-id | 20150813125845.GV3685@tamriel.snowman.net Whole thread Raw |
In response to | Re: WIP: SCRAM authentication (Robert Haas <robertmhaas@gmail.com>) |
List | pgsql-hackers |
* Robert Haas (robertmhaas@gmail.com) wrote: > On Wed, Aug 12, 2015 at 9:36 PM, Stephen Frost <sfrost@snowman.net> wrote: > >> 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 agree that such similar vulnerabilities would be unfortunate, but > > the way to avoid that is to not implement the actual hashing or > > encryption algorithms ourselves and to stick to the protocol as defined > > in the specification. > > Nothing in that will protect us if the client can request a non-SCRAM > form of authentication. The exact same risk exists for OpenSSL, as you mention, but also for Kerberos-based authentication systems as well. The way to address those risks is to not have an md5-based password verifier for the role. If only one password verifier exists per role then it makes moving off of md5 more difficult. I am not proposing a solution where both verifiers exist forever and I specifically proposed that we even remove all MD5 based verifiers in the future, similar to how older encryption algorithms are no longer supported by modern releases of MIT Kerberos. > >> 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. > > > > I attempted to address that also by stating that, should an attacker > > compromise a system with the goal of gaining the cleartext password, > > they would attempt the following, in order: > > What if they steal a pg_dump? All of the password verifiers are > there, but the live system is not. From my previous list, 4, 5, and 6 are all data-at-rest attacks. My comments below the list also indicated my feeling about the data-at-rest attacks, but to clarify, I strongly feel that an attacker would go after the md5 hash far before even considering attacking either the SCRAM password verifier or trying to use the combination of the two in a novel way. That isn't to say that there's no way the combination couldn't be combined or that having both doesn't increase the risk- it certainly does, but that exposure risk is really that we would then have two algorithms on which we depend on to not be broken, for the period of time that both are current. More generally, however, the way to address these kinds of data-at-rest attacks and loss of backup data is to have a password aging system where the passwords are changed on a regular basis. I certainly feel that we should be looking to add that functionality and that we need to step up and seriously move forward on implementing these capabilities that other systems have had for decades or more. We have excellent examples of what enterprise authentication systems do and the kinds of capabilities which they provide, both directly from examples such as Active Directory and PAM, but also from requirements definitions used around the world (eg: PCI compliance, NIST standards, and similar standards used by other governments). Thanks, Stephen
pgsql-hackers by date: