Re: SCRAM authentication, take three

On 04/10/2017 02:19 AM, Noah Misch wrote:
> On Fri, Apr 07, 2017 at 10:28:59AM +0300, Heikki Linnakangas wrote:
>> On 04/07/2017 08:21 AM, Noah Misch wrote:
>>> Michael shared[1] better pg_hba.conf syntax on 2016-11-05. I agreed[2] with
>>> his framing of the problem and provided two syntax alternatives, on
>>> 2017-01-18. Michael implemented[3] a variation of one of those on 2017-02-20,
>>> which you declined in your 2017-03-07 commit with just the explanation quoted
>>> above. I say Michael came up with something better five months ago.
>>
>> OK. My feeling is that we should have a relatively short and
>> easy-to-pronounce name for it. People editing pg_hba.conf with a text editor
>> will need to type in the keyword, and "scram" is a lot easier to remember
>> than "scram-sha-256". The word will also be used in conversations, "hey,
>> Noah, can you add example.com to the hba file, with scram, please?" If md5
>> had a more difficult name, I think we would've come up with a shorthand for
>> it back in the day, too.
>>
>> I might be wrong, of course. I don't set up PostgreSQL installations for a
>> living, so I might be out of touch of what's important.
>
> Likewise, but I've never seen pg_hba.conf edits become a large slice of
> PostgreSQL DBA work. Whereas experts can appreciate terse query syntax,
> pg_hba.conf syntax gains little from terseness.
>
>> In [1], Michael wrote:
>>> There is also the channel binding to think about... So we could have a
>>> list of keywords perhaps associated with SASL? Imagine for example:
>>> sasl $algo,$channel_binding
>>> Giving potentially:
>>> sasl scram_sha256
>>> sasl scram_sha256,channel
>>> sasl scram_sha512
>>> sasl scram_sha512,channel
>>> In the case of the patch of this thread just the first entry would
>>> make sense, once channel binding support is added a second
>>> keyword/option could be added. And there are of course other methods
>>> that could replace SCRAM..
>>
>> It should also be possible to somehow specify "use channel binding, if the
>> client supports it".
>>
>> I don't think "sasl" is interesting to a user, it's the actual mechanisms
>> (e.g "scram-sha256") that matter. So I'd suggest that we allow a list of
>> algorithms in the method field. If we go with the longer "scram-sha-256"
>> name, it would look like this:
>>
>> # TYPE DATABASE USER ADDRESS METHOD
>> host all all example.com scram-sha-256-plus,
>> scram-sha-256
>
> I agree "sasl" focuses on a less-interesting aspect of the authentication
> method. Allowing multiple methods per HBA line may be the better answer, so
> long as the policy questions it raises aren't too thorny. Do you allow any
> combination of methods or limit it somehow (e.g. only SASL methods)? If the
> same option pertains to two methods, do we provide a way to set the option on
> just one method? Those don't seem too challenging, though.
>
>> The problem again is that those names are quite long. Is that OK?
>
> Yes.
>
> With this, you could have a meta-method name (e.g. "default") that stands for
> all methods generally considered safe. Compare SSL default cipher lists.
>
>> In [2], you wrote:
>>> The latest versions document this precisely, but I agree with Peter's concern
>>> about plain "scram". Suppose it's 2025 and PostgreSQL support SASL mechanisms
>>> OAUTHBEARER, SCRAM-SHA-256, SCRAM-SHA-256-PLUS, and SCRAM-SHA3-512. What
>>> should the pg_hba.conf options look like at that time? I don't think having a
>>> single "scram" option fits in such a world. I see two strategies that fit:
>>>
>>> 1. Single "sasl" option, with a GUC, similar to ssl_ciphers, controlling the
>>> mechanisms to offer.
>>> 2. Separate options "scram_sha_256", "scram_sha3_512", "oauthbearer", etc.
>>
>> The example I gave above is like option 2. The problem with option 1 is that
>> different SASL mechanisms can have very different properties. You might want
>> to allow "NTLM" from a trusted network, but require "OTP" from the public
>> internet, for example. So I don't think a single GUC would be flexible
>> enough.
>>
>> That said, a GUC with a more narrow scope might be OK. If we called the
>> method in pg_hba.conf "secure_password", and had a GUC to list which
>> password-based mechanisms are considered secure, that would be OK. But I
>> think we'd still need a separate pg_hba.conf method name for OAUTHBEARER,
>> for example.
>
> Michael replied to my message with the idea to use a mechanism= HBA option.
> That's better than a GUC.
>
>> PS. If we go with the full names, I think it should "scram-sha-256", rather
>> than "scram_sha_256", because the official name uses dashes rather than
>> underscores.
>
> Agreed, I don't remember why I wrote underscores. One could argue on that
> basis for using uppercase, but I won't.
>
>
> These are the two chief approaches I'm seeing:
>
> 1. scram-sha-256, scram-sha-256-plus, and successors will be their own
> pg_hba.conf authentication methods. Until and unless someone implements an
> ability to name multiple methods per HBA line, you must choose exactly one
> SASL method. The concrete work for v10 would be merely renaming "scram" to
> "scram-sha-256".
>
> 2. Create a multiplexed authentication method like "sasl" or "scram" (not to
> be confused with today's "scram" method, which denotes SCRAM-SHA-256
> precisely). The DBA permits concrete methods like scram-sha-256 via HBA
> option. Absent that option, the system could default to a reasonable list.
>
> I had been favoring (2), but I'm starting to like (1) more. (2) assumes all
> SASL methods or all SCRAM methods have something in common with each other and
> not with other methods, and that's not so. For example, one might implement
> simultaneous md5 and scram-sha-256. (1) is harder to implement, but we can
> defer that work indefinitely.

One thing to consider is that we just made the decision that "md5"
actually means "md5 or scram-sha-256". Extrapolating from that, I think
we'll want "scram-sha-256" to mean "scram-sha-256 or scram-sha-256-plus"
(i.e. the channel-bonding variant) in the future. And if we get support
for scram-sha-512, "scram-sha-256" would presumably allow that too.

Given that, we don't necessarily even need to support a list of methods,
if we always implicitly also allow anything stronger than what's
specified. At least until someone implements something completely
different like OAUTHBEARER, that's not clearly stronger or weaker than
the other methods.

- Heikki