Re: WIP: SCRAM authentication

On Tue, Aug 11, 2015 at 2:35 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On 8/11/15 10:28 AM, Robert Haas wrote:
>> Right. So what? First, you upgrade all of the clients one by one to
>> a new version of the connector that supports SCRAM.
>
> In my experience, upgrading clients is, in many settings, significantly
> harder than upgrading servers. So I think any plan to starts like the
> above isn't going to work.

Well, the real sequence of steps is actually:

1. Get SCRAM authentication committed to 9.6, and release 9.6.
2. Get driver authors to begin supporting SCRAM in their drivers.
3. Get users to update to those new drivers.
4. Enable SCRAM authentication for any given role once all clients
that need that role are SCRAM-capable.

Since supporting a new authentication method means adding a new
protocol message, there's no feasible method for rolling out SCRAM
without users at some point updating to a newer driver. So there's
really not much choice but for (1)-(3) to happen. If you're saying
it's likely to be a really long time before steps (2) and (3) are
completed for substantially all installations, I quite agree.

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

We don't actually have any reason to believe that MD5 is insecure in
the way that we're using it. But if it turns out that somebody finds
an effective preimage attack against MD5, which I think what is what
Heikki said it would take to make our use unsafe, then it's not going
to be good enough to let people use SCRAM. They're going to need to
enforce the use of SCRAM. So I really don't understand why we want to
add a lot of complexity to let people mix the two authentication types
on the same user account. Unless SCRAM is the ONLY way to
authenticate to the server, the fact that some clients are using it
does not help you.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company