Re: reducing our reliance on MD5

On 02/11/2015 02:31 PM, Magnus Hagander wrote:
>
> In any case, my larger point was that given the pain that we're
> going to
> incur here, and the certainly years-long transition interval involved,
> it would be foolish to think only about replacing the MD5
> algorithm and
> not about reconsidering the context we use it in. Stuff like
> unreasonably
> short salt values should be dealt with at the same time.
>
>
>
> All discussion seems to be about the protocol, which is also the
> harder problem, isn't it?
>
> ISTM that the more *important* thing to fix is the on-disk storage in
> pg_authid.

At least, looks like it would be the most urgent (and with no need for
clients breaking in the process, AFAICT)

> [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.

Adding a new system column with a text or enum representing the
algorithm that created the "hash" would go a lot towards fixing this
situation.
When/If the column isn't there, just assume "md5". This would allow for
transparent pg_upgrade.
Then, based on the "default_hash" (or something to the same effect) GUC,
automatically rewrite the hashes (and set the corresponding 'hash_type')
upon password change.

Please note that this allows for clients supporting it (be it natively
or by relying on an external SASL lib or the like) to request some
challenge-response mechanism ---such as SCRAM-SHA256--- when available.
In fact, some forms of challenge-response-ready hashes also support
"password" (plaintext) with the same authenticator, thereby perfectly
replacing the functionality we have today.
Existing implementation: Dovecot's CRAM-MD5 mechanism

Thanks,

/ J.L.