Re: SCRAM authentication, take three

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

> On 04/07/2017 10:38 AM, Magnus Hagander wrote:
>
>> 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)
>>
>
> I think the "SCRAM" part is more important than "SHA-256", so -1 on that.
>

If that is the important part, then I agree :) I am not entirely sure that
the scram part *is* more important though.

I think most users will be a lot more comfortable with "sha256" than
"scram" though. But I guess that says using scram-sha-256 is the correct
way.

> The main against using just "scram" is that it's misleading, because we
> implement SCRAM-SHA-256, rather than SCRAM-SHA-1, which was the first SCRAM
> mechanism, commonly called just SCRAM. As long as that's the only SCRAM
> variant we have, that's not too bad, but it becomes more confusing if we
> ever implement SCRAM-SHA-512 or SCRAM-something-else in the future. That's
> the point Noah made, and it's a fair point, but the question is whether we
> consider that to be more important than having a short name for what we
> have now.

Yeah, I agree we should be prepared for the future. And having "scram" and
"scram-sha-512" would definitely fall under confusing.

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

> Technically, the channel-binding variant is a separate SASL mechanism,
i.e. it has a separate name, SCRAM-SHA-256-PLUS. I'm not sure if >
users/admins think of it that way.

I bet they don't.

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

> You can't have two entries with the same type+database+user+address
combination, period. (Or if you do, the second one is ignored.)

That's exactly my point.

//Magnus