Horton

Re: Password identifiers, protocol aging and SCRAM protocol

Michael Paquier <michael.paquier@gmail.com>

View thread View on postgr.es
From: Michael Paquier <michael.paquier@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>, David Steele <david@pgmasters.net>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>, Valery Popov <v.popov@postgrespro.ru>
Date: 2016-03-22T13:48:54Z
Lists: pgsql-hackers 
On Mon, Mar 21, 2016 at 11:07 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> Well, I said before and I'll say again that I don't like the idea of
> multiple password verifiers.  I think that's an accident waiting to
> happen, and I'm not prepared to put in the amount of time and energy
> that it would take to get that feature committed despite not wanting
> it myself, or for being responsible for it afterwards.  I'd prefer we
> didn't do it at all, although I'm not going to dig in my heels.  I
> might be willing to deal with SCRAM itself, but this whole area is not
> my strongest suit.  So ideally some other committer would be willing
> to pick this up.

I won't bet my hand on that.

> But the problem isn't even just that somebody has to hit the final
> commit button - as we've both said, there's a woeful lack of any
> meaningful review on this thread, and this sort of change really needs
> quite a lot of review.

Yep.

> This has implications for
> backward-compatibility, for connectors that don't use libpq, etc.
> Really, I'm not even sure we have consensus on the direction.  I mean,
> Heikki's proposal to adopt SCRAM sounds good enough at a broad level,
> but I don't really know what the alternatives are, I'm mostly just
> taking his word for it, and like you say, there's been a fair amount
> of miscellaneous negativity floating around.

PAKE or J-PAKE are other alternatives I have in mind.

I have marked the patch as returned with feedback.
-- 
Michael

Commits

  1. Support SCRAM-SHA-256 authentication (RFC 5802 and 7677).

  2. Refactor SHA2 functions and move them to src/common/.

  3. Replace isMD5() with a more future-proof way to check if pw is encrypted.

  4. Remove bogus notice that older clients might not work with MD5 passwords.

  5. Refactor the code for verifying user's password.

  6. Replace PostmasterRandom() with a stronger source, second attempt.

  7. Remove support for (insecure) crypt authentication.