Re: pg_authid.rolpassword format (was Re: Password identifiers, protocol aging and SCRAM protocol)
Stephen Frost <sfrost@snowman.net>
From: Stephen Frost <sfrost@snowman.net>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>, David Steele <david@pgmasters.net>, Tom Lane <tgl@sss.pgh.pa.us>, David Fetter <david@fetter.org>, Alvaro Herrera <alvherre@2ndquadrant.com>, Magnus Hagander <magnus@hagander.net>, Julian Markwort <julian.markwort@uni-muenster.de>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>, Valery Popov <v.popov@postgrespro.ru>
Date: 2016-12-17T01:23:22Z
Lists: pgsql-hackers
Michael, * Michael Paquier (michael.paquier@gmail.com) wrote: > On Sat, Dec 17, 2016 at 5:42 AM, Stephen Frost <sfrost@snowman.net> wrote: > > * Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote: > >> On 12/15/16 8:40 AM, Stephen Frost wrote: > >> > I don't follow why we can't change the syntax for CREATE USER to allow > >> > specifying the verifier type independently. > >> > >> That's what the last patch set I looked at actually does. > > > > Well, same here, but it was quite a while ago and things have progressed > > since then wrt SCRAM, as I understand it... > > From the discussions of last year on -hackers, it was decided to *not* > have an additional column per complains from a couple of hackers It seems that, at best, we didn't have consensus on it. Hopefully we are moving in a direction of consensus. > (Robert you were in this set at this point), and the same thing was > concluded during the informal lunch meeting at PGcon. The point is, > the existing SCRAM patch set can survive without touching at *all* the > format of pg_authid. We could block SCRAM authentication when > "password" is used in pg_hba.conf and as well as when "scram" is used > with a plain password stored in pg_authid. Or look at the format of > the string in the catalog if "password" is defined and decide the > authentication protocol to follow based on that. As I mentioned up-thread, moving forward with minimal changes to get SCRAM in certainly makes sense, but I do think we should be open to (and, ideally, encouraging people to work towards) having a seperate table for verifiers with independent columns for type and verifier. Thanks! Stephen
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