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>, Andres Freund <andres@anarazel.de>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
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>,
Stephen Frost <sfrost@snowman.net>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>,
Valery Popov <v.popov@postgrespro.ru>
Date: 2016-12-13T01:43:22Z
Lists: pgsql-hackers
On Mon, Dec 12, 2016 at 11:39 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote: > A few couple more things that caught my eye while hacking on this: > > 1. We don't use SASLPrep to scrub username's and passwords. That's by > choice, for usernames, because historically in PostgreSQL usernames can be > stored in any encoding, but SASLPrep assumes UTF-8. We dodge that by passing > an empty username in the authentication exchange anyway, because we always > use the username we got from the startup packet. But for passwords, I think > we need to fix that. The spec is very clear on that: > >> Note that implementations MUST either implement SASLprep or disallow >> use of non US-ASCII Unicode codepoints in "str". > > 2. I think we should check nonces, etc. more carefully, to not contain > invalid characters. For example, in the server, we use the read_attr_value() > function to read the client's nonce. Per the spec, the nonce should consist > of ASCII printable characters, but we will accept anything except the comma. > That's no trouble to the server, but let's be strict. > > To summarize, here's the overall TODO list so far: > > * Use SASLPrep for passwords. > > * Check nonces, etc. to not contain invalid characters. > > * Derive mock SCRAM verifier for non-existent users deterministically from > username. > > * Allow plain 'password' authentication for users with a SCRAM verifier in > rolpassword. > > * Throw an error if an "authorization identity" is given. ATM, we just > ignore it, but seems better to reject the attempt than do something that > might not be what the client expects. > > * Add "scram-sha-256" prefix to SCRAM verifiers stored in > pg_authid.rolpassword. > > Anything else I'm missing? > > I've created a wiki page, mostly to host that TODO list, while we hack this > to completion: https://wiki.postgresql.org/wiki/SCRAM_authentication. Feel > free to add stuff that comes to mind, and remove stuff as you push patches > to the branch on github. Based on the current code, I think you have the whole list. I'll try to look once again at the code to see I have anything else in mind. Improving the TAP regression tests is also an item, with SCRAM authentication support when a plain password is stored. -- 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