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.
