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

Josh,

* Josh Berkus (josh@agliodbs.com) wrote:
> I don't feel like you've correctly assessed the risk inherent in the
> md5 auth method, which is that, having captured an md5auth string by
> whatever means, and attacker can reuse that md5 string on other
> databases in the network *without* cracking it.  That's the biggest risk
> as long as md5 is present.

Robert and I, I believe, are both aware of that risk and had moved on to
discussing the risk to the cleartext password by keeping an md5 present,
even if it wasn't able to be used for login.  We will want to make it
simple for admins to enable/disable md5 (eg: pg_hba), but we also have
to consider how to make it simple for admins to remove the old md5
password verifier or there will be risk of the cleartext password being
compromised from backups, etc.

I fully agree that it's a serious risk that, today, what's stored in the
database is directly usable for logging into the running system (or any
system where the user has the same username and password).

> Aside from code complexity, the user security concern with a "multiple
> verifier per role" approach is that the DBAs would never remember to
> completely disable md5auth and would capture md5 hashes either in flight
> or from backups.  This approach can be used to capture an md5hash from a
> non-critical database which is poorly secured, and then re-use it
> against an important database.

The 'in flight' case is at least a bit less of an issue, as we don't
ship the password verifier directly over the network.  The backup
concern is certainly corret though.  I fully agree that we need a way to
make sure users don't end up having the old password verifiers around
longer than necessary.

That was the imputus for my earlier suggestion that in a release or two,
we actively make pg_upgrade error (or perhaps warn first, then error,
across two releases) if any of the old verifiers exist.

> Now, the counter-argument to this is that a DBA is just as likely to
> rememeber to remove md5 verifiers as she is to remember to remove roles
> with md5auth.

Indeed, that's a serious concern also.

The other concern with a single password verifier is that we're locking
ourselves into a one-verifier-per-role solution when most of the serious
solutions in use today (Active Directory, Kerberos, certificate based
systems) allow for more than one.

> Regardless of the approach we take, encouraging users to migrate is
> going to be more of a matter of documentation, publicity, and
> administrative tools than one of multiple verifiers vs. multiple roles.
>  That is, giving DBAs the ability to see and log who's using what kind
> of verifier, and what account has what verifier(s) available, will make
> more of a difference.

Fully agreed.
Thanks!
    Stephen