* Andrew Dunstan (andrew@dunslane.net) wrote:
> Tom Lane wrote:
> >It's worth pointing out also that adding a per-user-entry random salt
> >to the password protocol is not some kind of penalty-free magic bullet.
> >In particular it implies information leakage: I can tell from the
> >password challenge (or lack of one) whether the username I have offered
> >is valid. So rather than claiming "this is unconditionally a good thing
> >to do", you must actually provide a credible scenario that makes the
> >threat you are defending against more dangerous than the sorts of new
> >threats we'll be exposed to. So far I haven't seen a very credible
> >threat here.
>
> Ok, this made me think a bit. It's a valid point. I started off just
> thinking that you would send along the stored salt with the random
> session salt in something like the current AuthenticationMD5Password
> message, and if the user didn't exist send something faked out. But you
> would still get the information leak unless the faked out part could be
> consistent (inconsistency would imply an invalid user id), so it
> couldn't just be something random - you'd either have to make it
> algorithmic, which would kinda defeat the purpose, or keep a dictionary
> ... and we're back in much the same place we came in.
Can't keep a dictionary, of course. The algorithmic approach would
probably work- md5(username+pgsalt) where pgsalt is a random
per-installation salt, perhaps changed periodically, a random point once
a week or similar. The result of that md5 would then be truncated or
similar to provide the 'fake' salt to the client. md5's are pretty
cheap, I don't know that you could tell the difference between an md5
and a disk access (if it's not cache'd for whatever reason), esp. over a
network.
Changing the pgsalt shouldn't actually be a problem- that randomly
generated salt would change periodically anyway whenever a user changed
their password.
I'd also like to point out that this is *only* an issue for the 'md5'
authentication mechanism in pg_hba.conf, which I think should be
discouraged in favor of 'password' and SSL/IPSEC.
Thanks,
Stephen
