Re: Authentication mechanisms categorization

On Sat, Jul 8, 2017 at 2:19 PM, Álvaro Hernández Tortosa <aht(at)8kdata(dot)com> wrote:
> There has been some prior discussion, that we recently continued at
> pgday.ru, about what to do if a client wants to use a "strong"
> authentication mechanism but a rogue server forces the client to use a
> weaker authentication mechanism. This is the case if the client expects
> SCRAM to be used but a rogue server just replies with
> AuthenticationCleartextPassword, for example. Client drivers will
> authenticate using this latter mechanism, transparently (at least pgjdbc
> implementation does this, and I believe libpq also). This somehow defeats
> the purpose of some mechanisms like SCRAM.

Yeah :(

> It was discussed to add a parameter to the driver like "SCRAM-only", but
> I think this may not be ideal. "SCRAM-only" means that code needs to be
> written to prevent every other authentication mechanism, explicitly, which
> is far from ideal. Much worse, it defeats using other auth mechanisms that
> might be OK for the user. Also, this doesn't consider whether SCRAM is good
> without channel binding.
>
> I think it would be better to make a categorization of authentication
> mechanisms and then have an agreement among libpq and drivers to set a
> minimum level of security based on the user's request. Some initial ideas
> are:
>
> - Three security levels: Basic, Medium, Advanced.
> - Prevents MITM / does not.
> - Given this X possible attacks, a matrix of which mechanisms avoid which
> attacks (something similar to the table comparing the possible effects of
> the different isolation levels).
>
> This is not trivial: for example, SCRAM may be OK without channel
> binding in the presence of SSL, but without SSL channel binding is a must to
> prevent MITM. Similarly, are other auth mechanisms like Kerberos (I'm not an
> expert here) as "safe" as SCRAM with our without channel binding?

The use of channel binding is linked to SSL, which gets already
controlled by sslmode. Users won't get trapped in this area by using
"require" instead of the default of "prefer". I would love to see the
default value changed actually from "prefer" to "require" here.
"prefer" as a default is a trap for users. There were discussions
about that not long ago but this gave nothing.

> I believe this should be discussed and find a common agreement to be
> implemented by libpq and all the drivers, including a single naming scheme
> for the parameter and possible values. Opinions?

I think that we don't need to have anything complicated here: let's
have at least a connection parameter, and perhaps an environment
variable which enforces the type of the authentication method to use:
scram-sha-256, md5, etc. I don't think that there is any need to
support a list of methods, any application could just enforce the
parameter to a different value if the previous one failed.

Categorization is something that can lose value over the ages,
something considered as strong now could be weak in 10 years. By
supporting only a list of dedicated names users have the same
flexibility, and we just need to switch the default we consider safe.
Controlling SSL is already a separate and existing parameter, so I
don't think that it should be part of this scheme. Having
documentation giving a recommended combination, say
"authmethod=scram-sha-256 sslmode=require" would be enough IMO.
--
Michael