On Wed, Feb 11, 2015 at 9:14 AM, Magnus Hagander <magnus@hagander.net> wrote: > On Wed, Feb 11, 2015 at 3:10 PM, José Luis Tallón > <jltallon@adv-solutions.net> wrote: >> >> 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. > > > The hash value in pg_authid already contains "md5" as a prefix. No need for > another column.
How do we distinguish that from a password that actually starts with md5?
You mean one stored in cleatext? I don't know offhand :)
If it's actually stored with md5 (which it really should be) it's still the hash, but prefixed with the constant md5.
