Re: reducing our reliance on MD5 - Mailing list pgsql-hackers
| From | Magnus Hagander |
|---|---|
| Subject | Re: reducing our reliance on MD5 |
| Date | |
| Msg-id | CABUevEyn8y0oG7CJyzGwxaLywEnvg4q37+gWakK2qa_6qoewng@mail.gmail.com Whole thread Raw |
| In response to | Re: reducing our reliance on MD5 (Tom Lane <tgl@sss.pgh.pa.us>) |
| Responses |
Re: reducing our reliance on MD5
(José Luis Tallón <jltallon@adv-solutions.net>)
Re: reducing our reliance on MD5 (Claudio Freire <klaussfreire@gmail.com>) |
| List | pgsql-hackers |
On Wed, Feb 11, 2015 at 4:57 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Feb 10, 2015 at 9:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Another thing we need to keep in mind besides client compatibility
>> is dump/reload compatibility.
> I don't think there's an issue with dump/reload compatibility as far
> as what I proposed, since it only has to do with the authentication
> procedure, not what gets stored in pg_authid. We might have reasons
> for moving that away from MD5 as well, but it's a separate project.
Hm, well, that doesn't really square with your other expressed opinion:
>> Are there other goals?
> I think the goal is "stop using MD5, or at least have an option to not
> use MD5, because people think that's insecure".
As you say, it's quite debatable whether MD5 is or isn't secure enough
given the way we use it, but what's not debatable is that the optics of it
are not very good anymore. However, if we want to shut up the peanut
gallery on this point, we have to get rid of MD5 usage in pg_authid not
just the on-the-wire protocol --- I seriously doubt that the knee jerk
MD5-is-insecure crowd will make any distinction there. So I'm not
following how you're satisfied with a proposal for just the latter.
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.
If you actually worry about someone sniffing your network and mounting an attack against a password, you can use SSL. That means we already have a way to deal with that, whereas we don't have a way to mitigate the pg_authid thing. And also, if you are actually worried about someone sniffing an MD5'ed password, shouldn't you also worry about that same person sniffing all the *contents* of your database, which the password is there to protect?
(and in that regard, LDAP and such encryption algorithms send the password in clear text in that case....)
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.
pgsql-hackers by date: