Hi,
Am Do, den 19.08.2004 schrieb Tom Lane um 16:44:
> Oliver Elphick <olly@lfix.co.uk> writes:
> > I think the password can't be stored hash-digested because it has to be
> > encrypted with a salt established at runtime. If you could just send
> > the same hash-digested password over and over, it would be no more
> > secure than a plaintext one.
>
> [ looks at code... ] The actual algorithm is
>
> t = md5hash(cleartext_password || username);
> p = md5hash(t || salt);
> transmit p;
>
> where || means string concatenation. On the server side, t is the value
> actually stored in pg_shadow, so it just has to do the second step to
> obtain the value to compare to the password message.
>
> In theory we could make libpq accept the password in the form of t
> rather than cleartext_password, but I pretty much fail to see the point.
Actually it is a bit lame anyway ;) Since the database readable
string is really the key it does not matter how it is generated
in the first place. So in the current situation, there is no
advantage over clear text passwords then.
(Ok, it saves us from "over the shoulder looking") but not more.
Otoh, if one needs security, there is a pretty (open)ssl - layer
and it even supports client certificates...
Regards
Tino Wildenhain
PS: the hash would suit better when used in a challenge authorization,
meaning the server sends a random key, let the client
hash(random_key || md5( cleartext_password || username ) )
and compare it on server with
hash(random_key || stored_password)