Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On Thu, Jan 19, 2017 at 6:17 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> We seem to be caught between adding lots of new things as parameters
> and adding new detail into pg_hba.conf.
>
> Parameters like password_encryption are difficult here because they
> essentially repeat what has already been said in the pg_hba.conf. If
> we have two entries in pg_hba.conf, one saying md5 and the other
> saying "scram" (or whatever), what would we set password_encryption
> to? It seems clear to me that if the pg_hba.conf says md5 then
> password_encryption should be md5 and if pg_hba.conf says scram then
> it should be scram.
>
> I'd like to float another idea, as a way of finding a way forwards
> that will last over time
>
> * pg_hba.conf entry would say sasl='methodX' (no spaces)
> * we have a new catalog called pg_sasl that allows us to add new
> methods, with appropriate function calls

This would make sense if we support a mountain of protocols and that
we want to have a handler with a set of APIs used for authentication.
This is a grade higher than simple SCRAM, and this basically requires
to design a set of generic routines that are fine for covering *any*
protocol with this handler. I'd think this is rather hard per the
slight differences in SASL exchanges for different protocols.

> * remove password_encryption parameter and always use default
> encryption as specified for that session in pg_hba.conf

So if user X creates user Y with a password (defined by CREATE USER
PASSWORD) it should by default follow what pg_hba.conf dictates, which
could be pam or gss? That does not look very intuitive to me. The
advantage with the current system is that password creation and
protocol allowed for an authentication are two separate, independent
things, password_encryption being basically a wrapper for CREATE USER.
Mixing both makes things more confusing. If you are willing to move
away from password_encryption, one thing that could be used is just to
extend CREATE USER to be able to enforce the password protocol
associated, that's what the patches on this thread do with PASSWORD
(val USING protocol).

> Which sounds nice, but many users will wish to upgrade their current
> mechanisms from using md5 to scram. How will we update passwords
> slowly, so that different users change from md5 to scram at different
> times? Having to specify the mechanism in the pg_hba.conf makes that
> almost impossible, forcing a big bang approach which subsequently may
> never happen.

At this point comes the possibility to define multiple password types
for one single user instead of rolling multiple roles and renaming
htem.

> As a way of solving that problem, another idea would be to make the
> mechanism session specific depending upon what is stored for a
> particular user. That allows us to have a single pg_hba.conf entry of
> "sasl", and then use md5, scram-256 or future-mechanism on a per user
> basis.

Isn't that specifying multiple users in a single sasl entry in
pg_hba.conf? Once a user is updated, you could just move him from one
line to the other of pg_hba.conf, or use a @file in the hba entry.

> I'm not sure I see a clear way forwards yet, these are just ideas and
> questions to help the discussion.

Thanks, I find the catalog idea interesting. That's hard though per
the potential range of SASL protocols that have likely different needs
in the way messages are exchanged.
-- 
Michael