Re: MD5 authentication needs help - Mailing list pgsql-hackers

* Josh Berkus (josh@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