From: | Arthur Silva <arthurprs(at)gmail(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(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 01:14:56 |
Message-ID: | CAO_YK0Uyq+5S-vg8wnNOuPYwLT1z1srS=hSqxwVji2J=kmxm7Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Feb 10, 2015 at 10:32 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> On Tue, Feb 10, 2015 at 4:21 PM, Robert Haas <robertmhaas(at)gmail(dot)com>
> wrote:
> > Although the patch was described as relatively easy to write, it never
> > went anywhere, because it *replaced* MD5 authentication with bcrypt,
> > which would be a big problem for existing clients. It seems clear
> > that we should add something new and not immediately kill off what
> > we've already got, so that people can transition smoothly. An idea I
> > just had today is to keep using basically the same system that we are
> > currently using for MD5, but with a stronger hash algorithm, like
> > SHA-1 or SHA-2 (which includes SHA-224, SHA-256, SHA-384, and
> > SHA-512). Those are slower, but my guess is that even SHA-512 is not
> > enough slower for anybody to care very much, and if they do, well
> > that's another reason to make use of the new stuff optional.
>
> I believe that a big advantage of bcrypt for authentication is the
> relatively high memory requirements. This frustrates GPU based
> attacks.
>
>
> --
> Peter Geoghegan
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
There's also scrypt, which can be tuned for both memory and compute
requirements.
I don't think the "password storing best practices" apply to db connection
authentication. So SHA256 (or any other non terribly broken hash) is
probably fine for Pg.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2015-02-11 01:17:51 | Re: Show the LSN in rm_redo_error_callback |
Previous Message | Heikki Linnakangas | 2015-02-11 00:51:52 | Re: Assertion failure when streaming logical changes |