On Wed, Mar 4, 2015 at 03:54:09PM -0500, Tom Lane wrote: > Bruce Momjian <br...@momjian.us> writes: > > Let me update my list of possible improvements: > > > 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. > > > 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. > > > 4) Using the user name for the MD5 storage salt allows the MD5 stored > > hash to be used on the _same_ cluster. > > > 5) Using the user name for the MD5 storage salt causes the renaming of > > a user to break the stored password. > > What happened to "possession of the contents of pg_authid is sufficient > to log in"? I thought fixing that was one of the objectives here.
That is #4. Addressing Stephen's ideas, I question whether there are enough people who care about fixing #3 and #4 to require the use of TLS to fix it. It would be nice if we knew if the system was only using TLS, but we can't, so we would need a GUC for the administrator to choose always-TLS to fix #3 and #4. One way to fix #2 would be to use a per-user or per-cluster counter for the session salt, rather than a random number --- that would change replays from ~16k to 4 billion, with no wire protocol change needed. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers