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.
