From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Glen Parker <glenebob(at)nwlink(dot)com>, Pg-General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Is md5 really more secure than crypt? |
Date: | 2002-06-15 19:13:40 |
Message-ID: | 23630.1024168420@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
It occurs to me that we could make this work if we had a hash algorithm
that was commutative, in the sense that
hash(hash(a, b), c) = hash(hash(a, c), b)
for all possible passwords a and salts b, c. Then the idea
would be:
1. The value stored in pg_shadow is secret = hash(password, username)
same as now (or we could use some random salt, but we'd have to store
that salt too, so the username is probably as good as anything).
2. During connection start, pick a random salt and send it to the
client. The client computes response = hash(password, salt) and
sends it to the postmaster. Then the postmaster computes
hash(response, username) and hash(secret, salt) and compares these.
Commutativity would ensure that the values come out equal if the correct
password is supplied.
An attacker could figure out the value hash(secret, salt) if he'd seen
pg_shadow --- but if the hash function is strong then this does him no
good, because he won't be able to compute a response that will hash to
that target value.
MD5 is not commutative in this sense, and it might be that any hash
algorithm that is could not be cryptographically strong. But we could
look around and see what's out there...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jason Watkins | 2002-06-15 19:16:40 | Re: read this and puke |
Previous Message | Bruce Momjian | 2002-06-15 18:52:40 | Re: Is md5 really more secure than crypt? |