Re: reducing our reliance on MD5

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.

In response to

Responses

Browse pgsql-hackers by date

  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