Re: WIP: SCRAM authentication - Mailing list pgsql-hackers

From Robert Haas
Subject Re: WIP: SCRAM authentication
Date
Msg-id CA+TgmoZq6T=jsEr5sAW5Q3_63E4zaoim918e5fkb187AVmhr2g@mail.gmail.com
Whole thread Raw
In response to Re: WIP: SCRAM authentication  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: WIP: SCRAM authentication  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On Wed, Aug 12, 2015 at 10:50 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> 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.

Well, number one, I don't think we log anything currently that would
let you figure that out; and number two, I'm not sure I believe that's
the only way to make sure you've updated your clients.

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

Maybe we should try to find out how that played out.  It could inform
the current discussion.

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

Yeah.  I guess there's the scenario where you use SCRAM with clients
outside the firewall and MD5 with clients inside the firewall.  But,
meh.  For every person who benefits from the ability to configure
things that way, there will be 3 or 4 or 10 who enable SCRAM and never
get rid of their old password verifiers.  That will open up a
vulnerability for people to attack the old verifiers, or perhaps allow
some kind of attack where they can triangulate based on knowing that
the MD5 verifiers and the SCRAM verifier are based on the same
underlying password.

Another thing we might want to try to find out is: if we add SCRAM
authentication to 9.6, how committed are drivers authors to adding
that support to their drivers?  If we poll the maintainers of the
drivers for Perl, Python, Ruby, Node.JS, Java, ODBC, etc. and involve
them in this conversation, we might learn useful things.  This is a
big change we're talking about, and it's only to work (regardless of
the details) if the driver authors are on board.  We haven't, AFAIK,
talked to them about this at all.

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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: GinPageIs* don't actually return a boolean
Next
From: Robert Haas
Date:
Subject: Re: Raising our compiler requirements for 9.6