Re: Password identifiers, protocol aging and SCRAM protocol
David Steele <david@pgmasters.net>
From: David Steele <david@pgmasters.net>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Tom Lane <tgl@sss.pgh.pa.us>,
Robert Haas <robertmhaas@gmail.com>, David Fetter <david@fetter.org>,
Alvaro Herrera <alvherre@2ndquadrant.com>,
Magnus Hagander <magnus@hagander.net>,
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
Julian Markwort <julian.markwort@uni-muenster.de>,
Stephen Frost <sfrost@snowman.net>,
PostgreSQL mailing lists <pgsql-hackers@postgresql.org>,
Valery Popov <v.popov@postgrespro.ru>
Date: 2016-09-27T14:55:55Z
Lists: pgsql-hackers
On 9/26/16 2:02 AM, Michael Paquier wrote: > On Mon, Sep 26, 2016 at 2:15 AM, David Steele <david@pgmasters.net> wrote: > > Thanks for the review and the comments! > >> I notice that the copyright from pgcrypto/sha1.c was carried over but >> not the copyright from pgcrypto/sha2.c. I'm no expert on how this >> works, but I believe the copyright from sha2.c must be copied over. > > Right, those copyright bits are missing: > - * AUTHOR: Aaron D. Gifford <me@aarongifford.com> > [...] > - * Copyright (c) 2000-2001, Aaron D. Gifford > The license block being the same, it seems to me that there is no need > to copy it over. The copyright should be enough. Looks fine to me. >> Also, are there any plans to expose these functions directly to the user >> without loading pgcrypto? Now that the functionality is in core it >> seems that would be useful. In addition, it would make this patch stand >> on its own rather than just being a building block. > > There have been discussions about avoiding enabling those functions by > default in the distribution. We'd rather not do that... OK. >> * [PATCH 2/8] Move encoding routines to src/common/ >> >> I wonder if it is confusing to have two of encode.h/encode.c. Perhaps >> they should be renamed to make them distinct? > > Yes it may be a good idea to rename that, like encode_utils.[c|h] for > the new files. I like that better. >> Couldn't md5_crypt_verify() be made more general and take the hash type? >> For instance, password_crypt_verify() with the last param as the new >> password type enum. > > This would mean incorporating the whole SASL message exchange into > this routine because the password string is part of the scram > initialization context, and it seems to me that it is better to just > do once a lookup at the entry in pg_authid. So we'd finish with a more > confusing code I am afraid. At least that's the conclusion I came up > with when doing that.. md5_crypt_verify does only the work on a > received password. Ah, yes, I see now. I missed that when I reviewed patch 6. -- -David david@pgmasters.net
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