Re: reducing our reliance on MD5

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
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:34:52
Message-ID: CABUevEx_e_OAJFLG_Hz9iEHdzwq8LyZJHecXpS_QdmMh65q=Yw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 11, 2015 at 3:26 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

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

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-02-11 14:39:47 Re: assessing parallel-safety
Previous Message Robert Haas 2015-02-11 14:29:09 Re: 9.6 Feature help requested: Inclusion Constraints