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?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
