Vince Vielhaber <vev@michvhf.com> writes:
> When PG receives the password, it doesn't know if the password is
> encrypted or not.
What do you mean it doesn't know if the password is encrypted or not?
The protocol should tell it. You can't do this without a protocol
extension...
> Is there a preference to the method used?
I believe there was a very specific agreement about what the challenge
and response should be, and none of this looks like it. See the
discussion about how to have both wire security and encrypted-on-disk
passwords --- doing both is trickier than it sounds.
As far as the specific mechanics of applying MD5 go, I'd suggest
concatenating whatever strings need to go into a particular iteration
with appropriate separators (a null byte would probably do) and applying
MD5 just once. I can't see any reason to do things like
MD5(MD5(string1)+MD5(string2)). (IIRC there were places in the proposed
protocol where you'd be hashing a string previously hashed by the other
side, but that's not what I'm talking about here. Given particular
inputs to be combined, it seems sufficient to just concatenate them and
do one round of MD5.)
> If CL sends the MD5 of the username rather than the plaintext username,
> only CL and PG will know what the username is. PG will know it by
> comparing it with the MD5 of every username in pg_shadow. So even if the
> wire is being sniffed the unhashed username can be used in the password's
> encryption along with the salt sent by PG. This method will take longer
> for a user to log in, but the login process is only per session, not per
> SQL call.
A linear search of pg_shadow to log in is not acceptable; we don't want
to make login any slower than we have to. I see no real gain in security
from doing this anyway...
regards, tom lane
