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

From Greg Stark
Subject Re: WIP: SCRAM authentication
Date
Msg-id CAM-w4HOZh8U7QyT92o1oLEpEwyLmafbZHVmCCBTVGFnmOD2pwA@mail.gmail.com
Whole thread Raw
In response to Re: WIP: SCRAM authentication  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: WIP: SCRAM authentication  (Michael Paquier <michael.paquier@gmail.com>)
Re: WIP: SCRAM authentication  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Tue, Aug 18, 2015 at 7:19 PM, Robert Haas <robertmhaas@gmail.com> wrote:

> Sorry, that's a completely bogus argument.  We do not "need" to
> prevent people from upgrading if they haven't moved off of MD5
> authentication; that's just an arbitrary - and IMHO extremely
> user-hostile - policy decision.  We have a legitimate need, to move
> the project forward, to introduce a better system for password
> authentication.  Ripping out the old one is not a real need.  I'm sure
> at some point it will seem like antiquated cruft that nobody uses any
> more, but that will not be in "a year or two" or anything close to
> that.

I would imagine a GUC like enable_legacy_authentication=true which we
would just start defaulting to false after a few years and perhaps
consider removing five years after that. pg_upgrade could check if
there are any users which require it to be set to true and warn users
that they must enable it but should check the documentation so they
understand the impact.

> OK, that's an interesting argument.  If SCRAM supports multiple
> password verifiers, and we support SCRAM, then I guess we should
> probably do that, too.  I still don't like it all that much, though.
> I think it's absolutely inevitable that people are going to end up
> with an account with 3 or more different passwords that can all be
> used to log into it, and that won't be good.  How do other systems
> avoid this pitfall?

Fwiw having multiple passwords would make automated credential
rotations *so* much easier. Heroku has a really baroque solution to
this problem in Postgres involving creating new child roles and
swapping them around. My team in Google wasted many man hours dealing
with fallout from the quarterly password rotations.

(I wish we could just drop the account management and authentication
system entirely and dump the whole work on a system designed for this
particular problem. It's a hard problem that's far outside our core
features and Postgres is never going to be a good system for anyone
let alone everyone when there are many different types of users.)

-- 
greg



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: a few doubts around check_for_isn_and_int8_passing_mismatch
Next
From: Kevin Grittner
Date:
Subject: Re: Bug? ExecChooseHashTableSize() got assertion failed with crazy number of rows