From: | José Luis Tallón <jltallon(at)adv-solutions(dot)net> |
---|---|
To: | Claudio Freire <klaussfreire(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: reducing our reliance on MD5 |
Date: | 2015-02-11 14:48:57 |
Message-ID: | 54DB6BD9.4000703@adv-solutions.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
/ J.L.
From | Date | Subject | |
---|---|---|---|
Next Message | Claudio Freire | 2015-02-11 14:55:33 | Re: reducing our reliance on MD5 |
Previous Message | José Luis Tallón | 2015-02-11 14:41:17 | Re: reducing our reliance on MD5 |