* Josh Berkus (j...@agliodbs.com) wrote: > Catching up here ... > > On 03/03/2015 06:01 PM, Bruce Momjian wrote: > > It feels like MD5 has accumulated enough problems that we need to start > > looking for another way to store and pass passwords. The MD5 problems > > are: > > > > 1) MD5 makes users feel uneasy (though our usage is mostly safe) > > > > 2) The per-session salt sent to the client is only 32-bits, meaning > > that it is possible to reply an observed MD5 hash in ~16k connection > > attempts. > > Seems like we could pretty easily increase the size of the salt. Of > course, that just increases the required number of connection attempts, > without really fixing the problem.
Please do not propose hacks on top of the existing "md5" authentication method which break the wireline protocol. There is absolutely nothing useful to be gained from that. We need to introduce a new auth method with whatever protocol changes that requires without breaking the existing auth method. Discussing trade-offs of changing the existing md5 mechanism *without* breaking the wireline protocol may be worthwhile as we might be able to improve things a bit there, but nothing there is a proper solution for security conscious individuals. > > 3) Using the user name for the MD5 storage salt allows the MD5 stored > > hash to be used on a different cluster if the user used the same > > password. > > This is a feature as well as a bug. For example, pgBouncer relies on > this aspect of md5 auth. It's not a feature and pgBouncer could be made to not rely on this. > > 4) Using the user name for the MD5 storage salt causes the renaming of > > a user to break the stored password. > > Wierdly, in 17 years of Postgres, I've never encountered this issue. I agree, that's kind of odd. :) > So, are we more worried about attackers getting a copy of pg_authid, or > sniffing the hash on the wire? They are both attack vectors to consider but most applications address the network-based risk through TLS and have a hash-based approach to address the pg_authid-based risk. Administrators are used to that and are quite surprised to discover that PG doesn't work that way. As I mentioned up-thread, it's certainly very rare for anyone concerned about a network-based risk to *not* use TLS, but they tend to still use passwords for the actual authentication mechansim and the md5 auth mech makes the wrong trade-off for them. The password auth mech isn't ideal either since the server ends up seeing the PW. The change I'm suggesting addresses both the pg_authid-based risk and the "server seeing the PW" risk without changing the wireline protocol. Thanks, Stephen
Description: Digital signature