Stephen Frost <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
