Re: WIP: SCRAM authentication

On Mon, Aug 10, 2015 at 3:42 AM, 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.
>
> [...]

>> and the amount of
>> infrastructure we're proposing to introduce to support that is pretty
>> substantial.

Maybe. But that's worth it IMO. I think that we should keep in mind as
well that we may not stick with SCRAM forever either and that we may
have to do a similar recommended-protocol switch at some point. Or
that we may have to implement additional authorization protocols in
parallel to what we have which would still require manipulation of
multiple verifiers per role.

> ... during my exchange with Michael, I was thinking about the bug
> potential of taking the password field and multiplexing it in some way,
> which is significant. There is a definite risk of "making this too
> complicated" and we'll need to contrast that against ease-of-migration,
> because complicated mechanisms tend to be less secure due to user error.

Sure. That's why I am all in for adding a compatibility GUC or similar
that enforces the removal of old verifier types after marking those as
deprecated for a couple of years as there's surely a significant risk
to keep old passwords around or bad pg_hba entries. Still we need IMO
a way for a user to save multiple verifiers generated from a client to
manage carefully the password verifier aging, deprecations and support
removal.
--
Michael