On 9/28/09, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Actually there's a much bigger problem with asking the backend to reject
> weak passwords: what ya gonna do with a pre-MD5'd string? Which is
> exactly what the backend is going to always get, in a security-conscious
> environment.
Hmm... Looking at the docs, I don't see anywhere mention that the MD5
hashed passwords can still be used to log in, that only thing MD5'ing
protects from is actually knowing what the password was.
Also, although it does protect from sniffing password at login time,
it is as insecure as plaintext password against sniffing on
CREATE/ALTER USER time.
Thus only secure way to change password is over SSL, in which case
it does not make much difference whether it's plaintext or not.
Logfile may seem to be as argument against plaintext, but note
that you still cannot allow unprivileged users to access logfile
that may contain MD5 passwords, as they can use them to log in
as another user.
So promoting the ENCRYPTED 'foo' as "secure" may lure users into
false sense of security, and be lax against sniffing and logfile
protection.
Better approach seems to be simply refuse to log the password
value into logfile, whether it's MD5 or not, and promote SSL
as only secure way of changing passwords.
IOW, having plaintext password in CREATE/ALTER time which can
then checked for weaknesses is better that MD5 password, which
actually does not increase security.
We just need to fix the logging.
--
marko