Re: Successor of MD5 authentication, let's use SCRAM

(reviving an old thread)

On 23.10.2012 19:53, Peter Eisentraut wrote:
> On 10/22/12 1:25 PM, Stephen Frost wrote:
>> * Peter Eisentraut (peter_e@gmx.net) wrote:
>>> On 10/12/12 3:44 PM, Stephen Frost wrote:
>>>> In general, I think it's good to build on existing implementations where
>>>> possible.  Perhaps we could even consider using something which already
>>>> exists for this?
>>>
>>> Sounds like SASL to me.
>>
>> aiui, that would allow us to support SCRAM and we could support
>> Kerberos/GSSAPI under SASL as well...  Not sure how comfortable folks
>> would be with moving to that though.
>
> Considering all the design and implementation challenges that have been
> brought up in this thread:
>
> - not using MD5
>
> - not using whatever we replace MD5 with when that gets broken
>
> - content of pg_shadow can be used to log in
>
> - questions about salt collisions
>
> - making the hash more expensive
>
> - negotiating how much more expensive, allowing changes in the future
>
> - using HMAC to guard against length-extension attacks
>
> - support for poolers/proxies
>
> I think I would be less comfortable with a hand-crafted solution to each
> of these issues, and would be more comfortable with using an existing
> solution that, from the look of it, already does all of that, and which
> is used by mail and LDAP servers everywhere.
>
> That said, I don't have any experience programming SASL clients or
> servers, only managing existing implementations.  But I'd say it's
> definitely worth a look.

SASL seems like a good approach to me. The SASL specification leaves it 
up to the application protocol how the SASL messages are transported. 
Each application protocol that uses SASL defines a "SASL profile", which 
specifies that. So for PostgreSQL, we would need to document how to do 
SASL authentication. That's pretty straightforward, the SASL messages 
can be carried in Authentication and PasswordMessage messages, just like 
we do for GSS.

SASL specifies several "methods", like PLAIN and GSSAPI. It also has a 
couple of methods that use MD5, which probably could be used with the 
hashes we already store in pg_authid. I believe we could map all the 
existing authentication methods to SASL methods. In the distant future, 
we could deprecate and remove the existing built-in authentication 
handshakes, and always use SASL for authentication.

The SASL specification is quite simple, so I think we could easily 
implement it ourselves without relying on an external library, for the 
authentication methods we already support. That doesn't buy us much, but 
would be required if we want to always use SASL for authentication. On 
top of that, we could also provide a configure option to use an external 
SASL library, which could provide more exotic authentication methods.


Now, to a completely different approach:

I just found out that OpenSSL has added support for SRP in version 
1.0.1. We're already using OpenSSL, so all we need to do is to provide a 
couple of callbacks to OpenSSL, and store SRP verifiers in pg_authid 
instead of MD5 hashes, and we're golden.

Well, not quite. There's one little problem: Currently, we first 
initialize SSL, then read the startup packet which contains the username 
and database to connect to. After that, we initialize database access to 
the specified database, and only then we proceed with authentication. 
That's not a problem for certificate authentication, because certificate 
authentication doesn't require any database access, but if we are to 
store the SRP verifiers in pg_authid, we'll need to database access much 
earlier. Before we know which database to connect to.

But that's just an implementation detail - no protocol changes would be 
required.

- Heikki