Horton

Re: Password identifiers, protocol aging and SCRAM protocol

José Luis Tallón <jltallon@adv-solutions.net>

View thread View on postgr.es
From: José Luis Tallón <jltallon@adv-solutions.net>
To: Robert Haas <robertmhaas@gmail.com>, Michael Paquier <michael.paquier@gmail.com>
Cc: 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-03-30T16:31:11Z
Lists: pgsql-hackers 
On 03/30/2016 06:14 PM, Robert Haas wrote:
> So basically the use of the ENCRYPTED keyword means "if it does 
> already seem to be the sort of MD5 blob we're expecting, turn it into 
> that". 

If it does NOT already seem to be... I guess?

> And we just rely on the format to distinguish between an MD5 verifier 
> and an unencrypted password. Personally, I think a good start here, 
> and I think you may have something like this in the patch already, 
> would be to split rolpassword into two columns, say rolencryption and 
> rolpassword. 

This inches closer to Michael's suggestion to have multiple verifiers 
per pg_authid user ...

> rolencryption says how the password verifier is encrypted and 
> rolpassword contains the verifier itself. Initially, rolencryption 
> will be 'plain' or 'md5', but later we can add 'scram' as another 
> choice, or maybe it'll be more specific like 'scram-hmac-doodad'.

May I suggest using  "{" <scheme>["."<encoding>] "}" just like Dovecot does?

e.g. "{md5.hex}e748797a605a1c95f3d6b5f140b2d528"

where no "{ ... }" prefix means just fallback to the old method of 
trying to guess what the blob contains?
     This would invalidate PLAIN passwords beginning with "{", though, 
so some measures would be needed.

> And then maybe introduce syntax like this: alter user rhaas set 
> password 'raw-unencrypted-passwordt' using 'verifier-method'; alter 
> user rhaas set password verifier 'verifier-goes-here' using 
> 'verifier-method'; That might require making verifier a key word, 
> which would be good to avoid. Perhaps we could use "password 
> validator" instead? 

I'd like USING best ... though by prepending the schema for ENCRYPTED, 
the required information is already conveyed within the verifier, so no 
need to specify it again :)


Just my .02€


     / J.L.

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.