* Greg Stark ([EMAIL PROTECTED]) wrote: > 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.
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
signature.asc
Description: Digital signature