Re: Password identifiers, protocol aging and SCRAM protocol

So, the consensus so far seems to be: We don't want the support for
multiple password verifiers per user. At least not yet. Let's get SCRAM
working first, in a way that a user can only have SCRAM or an MD5 hash
stored in the database, not both. We can add support for multiple
verifiers per user, password aging, etc. later. Hopefully we'll make
some progress on those before 9.7 is released, too, but let's treat them
as separate issues and focus on SCRAM.

I took a quick look at the patch set now again, and except that it needs
to have the multiple password verifier support refactored out, I think
it's in a pretty good shape. I don't like the pg_upgrade changes and its
support function, that also seems like an orthogonal or add-on feature
that would be better discussed separately. I think pg_upgrade should
just do the upgrade with as little change to the system as possible, and
let the admin reset/rehash/deprecate the passwords separately, when she
wants to switch all users to SCRAM. So I suggest that we rip out those
changes from the patch set as well.

In related news, RFC 7677 that describes a new SCRAM-SHA-256
authentication mechanism, was published in November 2015. It's identical
to SCRAM-SHA-1, which is what this patch set implements, except that
SHA-1 has been replaced with SHA-256. Perhaps we should forget about
SCRAM-SHA-1 and jump straight to SCRAM-SHA-256.

RFC 7677 also adds some verbiage, in response to vulnerabilities that
have been found with the "tls-unique" channel binding mechanism:

> To be secure, either SCRAM-SHA-256-PLUS and SCRAM-SHA-1-PLUS MUST be
> used over a TLS channel that has had the session hash extension
> [RFC7627] negotiated, or session resumption MUST NOT have been used.

So that doesn't affect details of the protocol per se, but once we
implement channel binding, we need to check for those conditions somehow
(or make sure that OpenSSL checks for them).

Michael, do you plan to submit a new version of this patch set for the
next commitfest? I'd like to get this committed early in the 9.7 release
cycle, so that we have time to work on all the add-on stuff before the
release.

- Heikki