Re: Password identifiers, protocol aging and SCRAM protocol - Mailing list pgsql-hackers

From José Luis Tallón
Subject Re: Password identifiers, protocol aging and SCRAM protocol
Date
Msg-id 56FBFF4F.9080505@adv-solutions.net
Whole thread Raw
In response to Re: Password identifiers, protocol aging and SCRAM protocol  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Password identifiers, protocol aging and SCRAM protocol
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [postgresSQL] [bug] Two or more different types of constraints with same name creates ambiguity while drooping.
Next
From: Markus Nullmeier
Date:
Subject: Re: WIP: Access method extendability