* Andrew Dunstan ([EMAIL PROTECTED]) 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
signature.asc
Description: Digital signature