Re: WIP: SCRAM authentication - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: WIP: SCRAM authentication |
Date | |
Msg-id | CA+TgmoYVE3Cg_HG=uZ_2NfMBbRstgNVMsOeVxHbfCUZfDhfxaA@mail.gmail.com Whole thread Raw |
In response to | Re: WIP: SCRAM authentication (Peter Eisentraut <peter_e@gmx.net>) |
Responses |
Re: WIP: SCRAM authentication
|
List | pgsql-hackers |
On Tue, Aug 11, 2015 at 2:35 PM, Peter Eisentraut <peter_e@gmx.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
pgsql-hackers by date: