Re: reducing our reliance on MD5

On Wed, Feb 11, 2015 at 4:13 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> 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.

So, this all sounds fairly nice if somebody's willing to do the work,
but I can't help noticing that you originally proposed adopting SCRAM
in 2012, and it's 2015 now.  So I wonder if anyone's really going to
do all this work, and if not, whether we should go for something
simpler.  Just plugging something else in for MD5 would be a lot less
work for us to implement and for clients to support, even if it is (as
it unarguably is) less elegant.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company