Re: Password identifiers, protocol aging and SCRAM protocol
Michael Paquier <michael.paquier@gmail.com>
From: Michael Paquier <michael.paquier@gmail.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Robert Haas <robertmhaas@gmail.com>, Julian Markwort <julian.markwort@uni-muenster.de>,
Magnus Hagander <magnus@hagander.net>, 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-07-02T22:32:41Z
Lists: pgsql-hackers
On Sun, Jul 3, 2016 at 4:54 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote: > 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. That's as well what I recall from the consensus at PGCon: only focus on the protocol addition and storage of the scram verifier. It was not mentioned directly but that's what I guess should be done. So no complains here. > 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. That's to consider. I don't thing switching to that is much complicated. > 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). Yes. > 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. Thanks. That's good news! Yes, I am still on track to submit a patch for CF1. -- Michael
Commits
-
Support SCRAM-SHA-256 authentication (RFC 5802 and 7677).
- 818fd4a67d61 10.0 landed
-
Refactor SHA2 functions and move them to src/common/.
- 273c458a2b3a 10.0 landed
-
Replace isMD5() with a more future-proof way to check if pw is encrypted.
- dbd69118c05d 10.0 landed
-
Remove bogus notice that older clients might not work with MD5 passwords.
- 7e3ae5455948 9.2.20 landed
- 470af1f41c8b 9.3.16 landed
- ada2cdb61015 9.4.11 landed
- 65a7f190b253 9.5.6 landed
- 7546c135dc30 9.6.2 landed
- 31c54096a18f 10.0 landed
-
Refactor the code for verifying user's password.
- e7f051b8f9a6 10.0 landed
-
Replace PostmasterRandom() with a stronger source, second attempt.
- fe0a0b5993df 10.0 landed
-
Remove support for (insecure) crypt authentication.
- 53a5026b5cb3 8.4.0 cited