From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | José Luis Tallón <jltallon(at)adv-solutions(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnakangas(at)vmware(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:26:23 |
Message-ID: | CA+TgmoZNih8eHJ8zuxhSekFy5s2AeU2Fz_4g-wgQMcL=-T73Qw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Feb 11, 2015 at 9:14 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Wed, Feb 11, 2015 at 3:10 PM, José Luis Tallón
> <jltallon(at)adv-solutions(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-02-11 14:29:09 | Re: 9.6 Feature help requested: Inclusion Constraints |
Previous Message | Abhijit Menon-Sen | 2015-02-11 14:20:13 | Re: What exactly is our CRC algorithm? |