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