On 08/12/2015 06:36 PM, Stephen Frost wrote:
> 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
>
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.
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.
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.
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'susing what kind
of verifier, and what account has what verifier(s) available, will make
more of a difference.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com