On 14/07/17 11:09, Michael Paquier wrote:
On Sat, Jul 8, 2017 at 2:19 PM, Álvaro Hernández Tortosa <a...@8kdata.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
