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.
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.
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?
Using the hash as a password-equivalent is a bad idea all around.
--
greg
