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.
