On Wed, Feb 11, 2015 at 11:48 AM, José Luis Tallón <jltal...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers