On Wed, Feb 11, 2015 at 11:48 AM, José Luis Tallón
<jltallon@adv-solutions.net> wrote:
> On 02/11/2015 03:39 PM, Claudio Freire wrote:
>>
>> [snip]
>> Seems the risk of someone either lifting pg_authid from disk or by hacking
>> the system and being postgres, thereby accessing passwords stored
>> somewhere
>> else, is actually the bigger problem. But also one that should be
>> reasonably
>> easy (TM) to fix in a backwards compatible way? (just rewrite with a new
>> hash whenever the password is changed, but keep reading md5 until they are
>> all replaced.
>> Problem with all challenge-response authentication protocols, is that
>> the hash you have stored has to match the hash you use on the wire
>> protocol.
>>
>> It's not like you can store a SHA and provide MD5 authentication.
>
>
> Yes, except that you can do "fallback to plaintext" if the client requests
> (S)CRAM-SHA and you have (S)CRAM-MD5 instead, allowing for some
> interoperability and backwards compatibility in the process: pre-change
> libpq/JDBC could authenticate using password to a server with just
> SCRAM-SHA512 credentials.
>
> In any case, just storing the "password BLOB"(text or base64 encoded) along
> with a mechanism identifier would go a long way towards making this part
> pluggable... just like we do with LDAP/RADIUS/Kerberos/PAM today.
Wait... you mean falling back to storing plaintext or falling back to
transmitting plaintext over the wire?
Both seem a step backwards IMO.
