"Magnus Naeslund(f)" <mag@fbab.net> writes:
> [ good summary ]
> md5hash = md5(md5(cleartxtpasswd+user)+md5salt)
> This is standard MAC / shared secret stuff.
> It's done do avoid sending clear text passwords (or even the stored md5
> password, to prevent brute force cracking) over the wire.
It might help to be a little more clear about the reasons for doing it
this way:
1. Including the username into the stored-password calculation is done
to make it unobvious if two users have chosen the same password.
2. Using a random salt in the challenge/response protocol is done to
prevent replay attacks (ie, even if an attacker has sniffed your
previous sessions and seen what you sent over the wire, it's unlikely to
help him log in himself; he'd need to be lucky enough to be challenged
with the same random salt as he'd seen used before.)
One thing this setup does *not* do is prevent an attacker who's seen the
contents of pg_shadow from logging in. He'd need to make a modified
client-side library so that he could inject md5(cleartxtpasswd+user)
directly into the middle of the calculation, but he could do that and
the server would be none the wiser. We consider this not a fatal
problem, because anyone who's been able to read pg_shadow is already
superuser in some guise, and hardly has need to steal any more database
passwords. It would be better if it weren't true, but we didn't see any
way to prevent that without either making the protocol vulnerable to
sniffing, or requiring true reversible crypto and not just a crypto hash
(which would create all sorts of export issues, at least for those of
us in the US).
regards, tom lane