Re: WIP: SCRAM authentication

On Sun, Aug 9, 2015 at 2:42 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> On 08/09/2015 08:09 AM, Robert Haas wrote:
>> Why do we need to be able to authenticate using more than one
>> mechanism? If you have some clients that can't support SCRAM yet, you
>> might as well continue using MD5 across the board until that changes.
>> You're not going to get much real security out of using MD5 for some
>> authentication attempts and SCRAM for other ones,
>
> Speaking as someone who has sheperded several clients through
> infrastructure upgrades, I have to disagree with this.
>
> First, people don't upgrade large infrastructures with multiple
> applications, ETL processes and APIs which connect with the database all
> at once. They do it one component at a time, verify that component is
> working, and then move on to the next one. Even within a single
> application, there could be many servers to upgrade, and you can't do
> them all simultaneously.

Right. So what? First, you upgrade all of the clients one by one to
a new version of the connector that supports SCRAM.
Second, once all of the clients that access a particular user account
can support SCRAM, you switch that account to use SCRAM. The problem
you're talking about here would arise if, say, the JDBC maintainers
ripped out MD5 support at the same time they added SCRAM support. But
that would be dumb.

> Second, you're forgetting hosted PostgreSQL, where there may be only one
> user available to each database owner. So assigning a new login role
> for SCRAM isn't even an option.

Why do I care about having some of my authentication to a particular
role happen via SCRAM if I can't have it all happen via SCRAM?
Presumably, the benefit of SCRAM is that it's more secure than MD5
authentication. So, if I can log into role X via MD5 but role Y only
via SCRAM, there might be some security benefit in that: an attacker
who can subvert MD5 but cannot subvert SCRAM can hack into role X but
not into role Y. Good. But allowing someone to authenticate to role
X via *either* SCRAM or MD5 doesn't help at all. In fact it's
strictly worse, from a security perspective, than allowing someone to
authenticate via exactly one of those two methods, because now if the
attacker can subvert *either* of them he can break into that account.

In the hosted PostgreSQL situation you mention, there are really only
two cases. Either all clients that need to log into that account can
support SCRAM, in which case we can use SCRAM and shut MD5 off. Or
else they don't, and then we need to leave MD5 enabled. But if we
have to leave MD5 enabled, then what exactly do we get out of using
SCRAM for some subset of the clients that can support it?

There may be a good answer to this question, but I don't think I've
seen it spelled out clearly.

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