Re: WIP: SCRAM authentication - Mailing list pgsql-hackers

Robert,

* Robert Haas (robertmhaas@gmail.com) wrote:
> 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:

No worries, thanks again for the clarification and my apologies for
misunderstanding and jumping to an incorrect assumption.

As for the question about MD5, I do feel that we're using it in about
the best way possible, but I don't feel it's a terribly secure algorithm
today.  I'd really like to see people moving away from it sooner rather
than later and that our defaults move to much more secure solutions.

> (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 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.

> 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:

1) attempt to compromise a superuser account, if not already done, and
then modify the system to get the 'password' auth mechanism to be used
whereby the password is sent in the clear

2) change the existing password, or encourge the user to do so and
somehow capture that activity

3) social engineering attacks

4) attempt to crack the md5 hash

5) attempt to crack the SCRAM password verifier

6) try to work out a way to use both the md5 hash and the SCRAM password
verifier to figure out the password

In terms of difficulty, while I believe the above is the right overall
ordering, the level of difficulty goes up seriously between 4 and 5,
with 6 requiring a level of expertise in hash algorithms and SCRAM that
I have a very hard time seeing anyone bothering to go there, rather than
just throw more CPUs at the md5 hash.
Thanks!
    Stephen