Re: Add "password_protocol" connection parameter to libpq

On Fri, 9 Aug 2019 at 11:00, Michael Paquier <michael(at)paquier(dot)xyz> wrote:

> On Thu, Aug 08, 2019 at 03:38:20PM -0700, Jeff Davis wrote:
> > Libpq doesn't have a way to control which password protocols are used.
> > For example, the client might expect the server to be using SCRAM, but
> > it actually ends up using plain password authentication instead.
>
> Thanks for working on this!
>
> > I'm not 100% happy with the name "password_protocol", but other names I
> > could think of seemed likely to cause confusion.
>
> What about auth_protocol then? It seems to me that it could be useful
> to have the restriction on AUTH_REQ_MD5 as well.
>
> > Sets the least-secure password protocol allowable when using password
> > authentication. Options are: "plaintext", "md5", "scram-sha-256", or
> > "scram-sha-256-plus".
>
> This makes it sound like there is a linear hierarchy among all those
> protocols, which is true in this case, but if the list of supported
> protocols is extended in the future it may be not.
>

Before we go too far along with this, lets look at how other established
protocols do things and the flaws that've been discovered in their
approaches. If this isn't done with extreme care then there's a large risk
of negating the benefits offered by adopting recent things like SCRAM.
Frankly I kind of wish we could just use SASL, but there are many (many)
reasons no to.

Off the top of my head I can think of these risks:

* Protocols that allow naïve pre-auth client/server auth negotiation (e.g.
by finding the overlap in exchanged supported auth-mode lists) are subject
to MiTM downgrade attacks where the attacker filters out protocols it
cannot intercept and break from the proposed alternatives.

* Protocols that specify a hierarchy tend to be inflexible and result in
hard to predict auth mode selections as the options grow. If my app wants
GSSAPI or SuperStrongAuth but doesn't accept SSPI, and the hierarchy is
GSSAPI > SSPI > SuperStrongAuth, it has to fall back to a disconnect and
retry model like now.

* Protocols that announce supported auth methods before any kind of trust
is established make life easier for vulnerability scanners and worms

and I'm sure there are more when it comes to auth handshakes.

--
Craig Ringer http://www.2ndQuadrant.com/
2ndQuadrant - PostgreSQL Solutions for the Enterprise