From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Joe Conway <mail(at)joeconway(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Marko Kreen <markokr(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Dave Page <dpage(at)pgadmin(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: sha1, sha2 functions into core? |
Date: | 2012-08-15 15:48:58 |
Message-ID: | 20120815154858.GI25473@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 15, 2012 at 11:37:04AM -0400, Andrew Dunstan wrote:
>
> On 08/15/2012 11:22 AM, Joe Conway wrote:
> >On 08/15/2012 06:48 AM, Tom Lane wrote:
> >>>On Wed, Aug 15, 2012 at 6:11 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >>>>Is there a TODO here?
> >>If anybody's concerned about the security of our password storage,
> >>they'd be much better off working on improving the length and randomness
> >>of the salt string than replacing the md5 hash per se.
> >Or change to an md5 HMAC rather than straight md5 with salt. Last I
> >checked (which admittedly was a while ago) there were still no known
> >cryptographic weaknesses associated with an HMAC based on md5.
> >
>
>
>
> Possibly. I still think the right time to revisit this whole area
> will be when the NIST Hash Function competition ends supposedly
> later this year. See
> <http://csrc.nist.gov/groups/ST/hash/timeline.html>. At that time we
> should probably consider moving our password handling to use the new
> standard function.
Are we really going to be comforable with a algorithm that is new?
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2012-08-15 15:49:50 | Re: sha1, sha2 functions into core? |
Previous Message | Peter Geoghegan | 2012-08-15 15:41:38 | Re: [COMMITTERS] pgsql: Revert "commit_delay" change; just add comment that we don't hav |