Re: Password identifiers, protocol aging and SCRAM protocol
От | José Luis Tallón |
---|---|
Тема | Re: Password identifiers, protocol aging and SCRAM protocol |
Дата | |
Msg-id | 56FBFF4F.9080505@adv-solutions.net обсуждение исходный текст |
Ответ на | Re: Password identifiers, protocol aging and SCRAM protocol (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Password identifiers, protocol aging and SCRAM protocol
|
Список | 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.
В списке pgsql-hackers по дате отправления: