Re: SCRAM authentication, take three

Jumping late into this one, apologies if these opinions have already been
up and discarded.

On Fri, Apr 7, 2017 at 9:28 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:

> On 04/07/2017 08:21 AM, Noah Misch wrote:
>
>> On Thu, Apr 06, 2017 at 09:46:29PM +0300, Heikki Linnakangas wrote:
>>
>>> On 04/06/2017 08:36 AM, Noah Misch wrote:
>>>
>>>> On Tue, Mar 07, 2017 at 02:36:13PM +0200, Heikki Linnakangas wrote:
>>>>
>>>>> I didn't include the last-minute changes to the way you specify this in
>>>>> pg_hba.conf. So it's still just "scram". I agree in general that we
>>>>> should
>>>>> think about how to extend that too, but I think the proposed syntax was
>>>>> overly verbose for what we actually support right now. Let's discuss
>>>>> that as
>>>>> a separate thread, as well.
>>>>>
>>>>
>>>> [Action required within three days. This is a generic notification.]
>>>>
>>>> The above-described topic is currently a PostgreSQL 10 open item.
>>>>
>>>
>>> I don't think we will come up with anything better than what we have
>>> now, so
>>> I have removed this from the open items list.
>>>
>>
>> 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.
>
> Reserving, as HEAD does today, keyword "scram" to mean "type of SCRAM we
>> introduced first" will look ugly in 2027. Cryptographic hash functions
>> have a
>> short shelf life compared to PostgreSQL.
>>
>
> I don't think that's such a big deal. Firstly, I don't think it would be
> too bad for "scram" to mean "the type of SCRAM we introduced first".
> Secondly, we can add an alias later, if we add support for a new mechanism
> in the SCRAM family.
>
> Our MD5 authentication method was introduced in 2001, I expect
> SCRAM-SHA-256 to also last about 15 years before we consider replacing it.
> Note that the big problem with our MD5 authentication is not actually the
> hash algorithm. There are still no practical pre-image attacks on MD5, even
> though it's thoroughly broken for collisions. If we had "SCRAM-MD5", it
> would still be OK. So I'd hazard a guess that whatever will eventually
> replace SCRAM-SHA-256, will not be SCRAM with a different hash algorithm,
> but something else entirely.
>

So here's a wild idea. What if we just call it "sha256"? Does the user
actually care about it being scram, or is scram just an implementation
detail for them? That way when the next one shows up, it'll be sha512 or
whatever. It happens to use scram under the hood, but does the user have to
or does the user want to care about that?

(One could argue the same way that the user shouldn't have to or want to
care about the hashing algorithm -- but if that's the case then we should
only have one entry, it would be "scram", and the system would decide from
there. And I think this discussion already indicates we don't think this is
enough)

>
> The channel binding aspect is actually more important to think about right
> now, as that we will hopefully implement in the next release or two.
>
> 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".
>

Is that really a type of authentication? We already hvae the idea of
authentication method options, used for most other things except md5 which
doesn't have any. So it could be "sha256 channelbind=on", "sha256
channelbind=off" or "sha256 channelbind=negotiate" or something like that?

> 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
>
> The problem again is that those names are quite long. Is that OK?

Not sure if it would be doable in the code, but we could also have:
host all all example.com scram method=sha256plus,sha256

or something like that. Which would fit within the current syntax of the
file. But I think it might not be enough, because then you couldn't have
two entries with different scram methods for the same combination of the
other fields -- the hba *matching* doesn't look at the options fields.

>
> 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.
>

+1.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/