Re: Authentication mechanisms categorization

On 14/07/17 11:09, Michael Paquier wrote:
> 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.

Hmmmm yes. As of today. Maybe tomorrow there's a channel binding
mechanism that does not make use of SSL. But this is also unlikely.

> 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.

If the parameter authmethod would rather be "authmethods", i.e., a
list, I think it would be significantly more flexible.

I agree with a list of methods and all the values already existing
for sslmode, this might be more than enough, specially if the channel
binding SCRAM mechanisms would get a different authmethod than their
non-channel binding partners (like scram-sha-256-plus). This makes the
list argument for the authmethods, in my opinion, stronger.

Álvaro

--

Álvaro Hernández Tortosa

-----------
<8K>data