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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
