Re: WIP: SCRAM authentication

On 03/30/2015 06:46 PM, Stephen Frost wrote:
> * Heikki Linnakangas (hlinnaka(at)iki(dot)fi) wrote:
>> * With "CREATE USER PASSWORD 'foo'", which hashes/verifiers should
>> be generated by default? We currently have a boolean
>> password_encryption setting for that. Needs to be a list.
>
> This generally sounds good to me but we definitely need to have that
> list of hashes to be used. The MIT KDC for Kerberos (and I believe all
> the other Kerberos implementations) have a similar setting for what will
> be stored and what will be allowed for hashing and encryption options.
> It's very important that we allow users to tweak this list, as we will
> want to encourage users to migrate off of the existing md5 storage
> mechanism and on to the SCRAM based one eventually.
>
> Unfortunately, the first major release with this will certainly need to
> default to including md5 as we can't have a password update or change
> break clients right off the bat. What I think would be fantastic would
> be a warning, perhaps in the first release or maybe the second, which
> deprecates md5 as an auth method and is thrown when a password is set
> which includes storing an md5-based password. I'm sure there will be
> plenty of discussion about that in the future.

Yeah. And even if client are updated, and the server is upgraded, you
still cannot use SCRAM until all the passwords have been changed and the
SCRAM verifiers for them generated. Unless we go with the scheme I
mentioned earlier, and use the MD5 hash of the password as the
"plaintext" password to SCRAM.

> One additional item is that we need to have a way to prefer SCRAM-based
> auth while allowing a fall-back to md5 if the client doesn't support it.
> This might have to be driven by the client side explicitly saying "I
> support SCRAM" from the start to avoid breaking existing clients.

I'll start a separate thread on this. It's an interesting feature on its
own. As well as an option in libpq to refuse plaintext authentication
even if the server asks for it.

>> * Per the SCRAM specification, the client sends the username in the
>> handshake. But in the FE/BE protocol, we've already sent it in the
>> startup packet. In the patch, libpq always sends an empty username
>> in the SCRAM exchange, and the username from the startup packet is
>> what matters. We could also require it to be the same, but in SCRAM
>> the username to be UTF-8 encoded, while in PostgreSQL the username
>> can be in any encoding. That is a source of annoyance in itself, as
>> it's not well-defined in PostgreSQL which encoding to use when
>> sending a username to the server. But I don't want to try fixing
>> that in this patch, so it seems easiest to just require the username
>> to be empty.
>
> I don't like having it be empty.. I'm not looking at the spec right at
> the moment, but have you confirmed that the username being empty during
> the SCRAM discussion doesn't reduce the effectiveness of the
> authentication method overall in some way?

Yes.

> Is it ever used in
> generation of the authentication verifier, etc? One way to address the
> risk which you bring up about the different encodings might be to simply
> discourage using non-UTF8-compliant encodings by throwing a warning or
> refusing to support SCRAM in cases where the role wouldn't be allowed by
> SCRAM (eg: in CREATE ROLE or ALTER ROLE when the SCRAM auth verifier
> storage is being handled). Another option might be to define a way to
> convert from "whatever" to "UTF8 something" for the purposes of the
> SCRAM auth method.

Presumably the username used in the SCRAM exchange would have to match
the username sent in the startup packet. Otherwise things get weird. If
an empty string is a problem (there actually seems to be some language
in the spec to forbid or at least discourage using an empty string as
username), we could also specify some other constant that must be used,
to mean "same as in startup packet".

- Heikki