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

From Stephen Frost
Subject Re: WIP: SCRAM authentication
Date
Msg-id 20150813015006.GU3685@tamriel.snowman.net
Whole thread Raw
In response to Re: WIP: SCRAM authentication  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
* Michael Paquier (michael.paquier@gmail.com) wrote:
> On Thu, Aug 13, 2015 at 10:22 AM, Stephen Frost wrote:
> >> The only case where I can see multiple verifiers per role making a real
> >> difference in migrations is for PGAAS hosting.  But the folks from
> >> Heroku and AWS have been notably silent on this; lemme ping them.
> >
> > While their insight is certainly valuable, they are certainly not the
> > only cases of one-user-to-rule-them-all environments.  Further, there's
> > going to be cases where multiple applications from different languages
> > are accessing the database through the same account because there's only
> > one account.
> >
> > I'd rather not punt on those cases and, further, assume that we'll
> > always be able to keep it to only one password verifier per account.  As
> > I tried to outline up-thread, there are a set of features which would be
> > very nice for us to have which require further information to be saved
> > beyond even these different password verifiers for each.
>
> While looking at this stuff, I have been wondering as well about
> moving the validutil field into the verifier catalog as well for
> example. That's one.

Agreed.

> > As mentioned elsewhere, even SCRAM is possible of having multiple
> > password verifiers based on the various algorithms used.  In other
> > words, I doubt the 'only one password verifier per role' approach is
> > going to work out for us long term in any case.
>
> SCRAM is a definition for an authorization protocol which includes
> many verifiers, and the minimal requirement to consider that SCRAM is
> implemented in a system is to have SCRAM-SHA1, per here:
> http://tools.ietf.org/html/rfc5802
> For example we may want to have in parallel one verifier for
> SCRAM-SHA1 and one for SCRAM-SHA256 for the same user, and I think
> that we cannot close the door either to other SASL protocols, which is
> why it may make sense to split the SCRAM patch into two with the basic
> message protocol infrastructure in place.

and further agreed here.  In addition, I'd point out that this is not a
novel area in secure applications- Kerberos/GSSAPI have long been doing
this, with both MIT Kerberos and Heimdal providing multiple algorithms
and supporting multiple password verifiers per user.  Active Directory
also, actually.  When it comes to enterprise authentication systems and
administrators who work with them, this is not overly complex nor
suprising.
Thanks!
    Stephen

pgsql-hackers by date:

Previous
From: Kouhei Kaigai
Date:
Subject: Our trial to TPC-DS but optimizer made unreasonable plan
Next
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Further fixes for degenerate outer join clauses.