On 8/11/15 5:18 PM, Robert Haas wrote:
> The thing we're actually debating here is whether enabling SCRAM
> authentication for a role should also mean disabling MD5
> authentication for that same role, or whether you should be able to
> have two password verifiers stored for that role, one for SCRAM and
> the other MD5. If we allowed that, then you could turn SCRAM on for a
> role, and only later turn MD5 off. I think that's a bad plan because,
> in most scenarios, allowing two forms of authentication for the same
> account is strictly less secure than allowing only one. And also
> because it means adding a bunch of new system catalog machinery and
> SQL syntax. Instead, I think that, for any given role, you should get
> to pick the way that password authentication works for that role:
> either MD5, or SCRAM, but not "whichever of those two the client
> prefers".
I understand this idea, but I think it's not practical for many uses.
There is no way to find out, on the server, whether all current clients
would support a switch to SCRAM. Let alone all not-current clients.
The only way to do such a switch would be to do the switch and then
check for connection failures in the log, which is not good.
It would be better if we allowed both methods side by side. Then an
administrator can check in the logs which clients are using an old
method and track those down without interrupting production.
(Now that I think about this, to counter my point, this is very similar
to the switch from crypt to md5. You couldn't turn that on until you
were sure that all clients would support it. I don't remember the
experience from back then, though.)
Also, correct me if I'm wrong, but I believe using SCRAM would also make
it harder to use the password exchange sniffed from the wire. So there
might be a benefit to using SCRAM even if you have to keep old and
supposedly insecure md5 hashes around for a while.
