* Greg Stark (gsstark@mit.edu) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > If you use 'md5' in pg_hba.conf then using 'with encrypted password'/md5
> > in pg_shadow is pointless because the authentication token is the hash
> > which is stored in cleartext in pg_shadow.
>
> The source of my confusion earlier was that I assumed the server used MD5
> hashes similarly to how Unix uses crypt hashes. It seems it's not, it's using
> MD5 hashes as password-equivalents. That's pretty silly. It means the original
> password isn't stored in the database which could help limit a compromise from
> escalating to other services that use the same password. But that's all it
> accomplishes.
>
> In the traditional way to use hashes in this circumstance the goal is to avoid
> storing a password-equivalent entirely. So the client would still send the
> original password, which would then be hashed and compared with the stored
> hash.
Right, exactly, that can be done in Postgres, you just have to use
'password' in pg_hba.conf instead of 'md5'. Because of the goal of
supporting the 'md5' method though it apparently was decided that the
salt for pg_shadow would be the username instead of a random salt (since
that would then have to be given to the client).
> In that plan leaking the hash isn't a security threat at all. You still have
> to provide the original password to log in, and you can't get that from the
> hash.
>
> The use of a salt is useful in that scenario because it prevents someone from
> being able to build a large dictionary of hashes in advance and look up the
> equivalent password quickly.
Yes, exactly. :)
> If the hash is a password-equivalent then I don't see the point of salts in
> the first place. All it means is if someone *does* compromise your postgres
> server then they can use a dictionary attack to pull out the original password
> and attack other services. But they've already compromised your database, is
> that really your biggest worry at that point?
Well, my goal is to not make the hash password-equivalent by not using
the method which makes it that way- 'md5' in pg_hba.conf. Then it makes
sense to use a salt, etc.
> Using the hash as a password-equivalent is a bad idea all around.
I agree completely, and thus move to discourage the 'md5' transport
method in pg_hba.conf in favor of 'password' and SSL/IPSEC.
Thanks,
Stephen
