Re: WIP: SCRAM authentication

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Wed, Aug 12, 2015 at 9:36 PM, Stephen Frost <sfrost(at)snowman(dot)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