On Wed, Mar 4, 2015 at 03:54:09PM -0500, Tom Lane wrote:
> Bruce Momjian <bruce@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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +