Re: [HACKERS] SCRAM authentication, take three - Mailing list pgsql-hackers
| From | Magnus Hagander |
|---|---|
| Subject | Re: [HACKERS] SCRAM authentication, take three |
| Date | |
| Msg-id | CABUevEytgZ=FGJpDFVF=JSGa_Q2L4mFYsaXUFcMfKBu3mTHfyg@mail.gmail.com Whole thread Raw |
| In response to | Re: [HACKERS] SCRAM authentication, take three (Heikki Linnakangas <hlinnaka@iki.fi>) |
| Responses |
Re: [HACKERS] SCRAM authentication, take three
(Álvaro Hernández Tortosa <aht@8kdata.com>)
|
| List | pgsql-hackers |
On Fri, Apr 7, 2017 at 9:59 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> 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.
> You can't have two entries with the same type+database+user+address combination, period. (Or if you do, the second one is ignored.)
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
pgsql-hackers by date: