[HACKERS] Authentication mechanisms categorization - Mailing list pgsql-hackers

From Álvaro Hernández Tortosa
Subject [HACKERS] Authentication mechanisms categorization
Date
Msg-id d4098ef4-2910-c8bf-f1e3-f178ba77c381@8kdata.com
Whole thread Raw
Responses Re: [HACKERS] Authentication mechanisms categorization
List pgsql-hackers
    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




pgsql-hackers by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: [HACKERS] New partitioning - some feedback
Next
From: David Fetter
Date:
Subject: [HACKERS] COPY vs. transition tables