Re: reducing our reliance on MD5 - Mailing list pgsql-hackers

On 02/11/2015 05:57 AM, Tom Lane wrote:
> In any case, my larger point was that given the pain that we're going to
> incur here, and the certainly years-long transition interval involved,
> it would be foolish to think only about replacing the MD5 algorithm and
> not about reconsidering the context we use it in.  Stuff like unreasonably
> short salt values should be dealt with at the same time.

+1. We should pick a well-documented mechanism with well-understood 
properties, rather than roll our own again.

Apart from the weaknesses in the MD5 authentication method itself, our 
protocol doesn't make it easy to add new methods and still support old 
clients gracefully. We should address that too.

For the first cut, I propose:

1. Implement SASL. The server sends a new AuthenticationSASLRequest 
message, to which the client responds with AuthenticationSASLResponse 
message. These messages carry the SASL challenge/response messages, 
until AuthenticationOK is received. Similar to our GSSAPI 
implementation. (Note that this doesn't require the use of any 3rd party 
libraries or such. The specification for SASL itself is very short and 
high-level.)

2. Add a way for the client and server to negotiate which authentication 
mechanism to use. Currently, the server dictates it to the client, and 
if it doesn't support that mechanism, it has to disconnect. To make it 
possible to add new mechanisms gracefully, with a long transition 
period, we need a way to negotiate. The server should send a list of 
allowed authentication methods in the first AuthenticationSASLRequest 
message, and the client picks one.

3. To support old clients that don't understand the new 
AuthenticationSASLRequest message, the client tells that it supports it 
before the authentication begins. It does that by tacking a special 
option "protocol.extensions=sasl" in the startup packet (more extensions 
could be added there in the future, as a comma-separated list). With 9.2 
and above servers, the server will ignore unrecognized options 
containing a dot. 9.1 and earlier will throw an error, but the client 
can then retry without the option, like libpq does for application_name.

4. Implement the SASL mechanism "SCRAM". That's a challenge/response 
password scheme, similar to the current MD5 authentication, but with 
better salt and more expensive computation (= more resistance to 
dictionary attacks).

5. Modify/add syntax to ALTER USER SET PASSWORD to allow storing the new 
SCRAM, and other, authentication information in pg_authid.

That's it for starters. The SCRAM mechanism is a fairly straightforward 
replacement for MD5. This scheme makes it possible to add more 
mechanisms later, without requiring all clients to immediately support them.

- Heikki