Re: Add "password_protocol" connection parameter to libpq

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: Add "password_protocol" connection parameter to libpq
Дата
Msg-id CAMsr+YF-pEPoeTVarW=JQ5xEHsqEs2fCpAfbmzvEjhfw1hEuAA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Add "password_protocol" connection parameter to libpq  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Add "password_protocol" connection parameter to libpq  (Jeff Davis <pgsql@j-davis.com>)
Список pgsql-hackers
Дерево обсуждения
On Fri, 9 Aug 2019 at 11:00, Michael Paquier <michael@paquier.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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)