Re: reducing our reliance on MD5

<div dir="ltr"><br /><div class="gmail_extra"><br /><div class="gmail_quote">On Tue, Feb 10, 2015 at 10:32 PM, Peter
Geoghegan<span dir="ltr"><<a href="mailto:pg@heroku.com" target="_blank">pg@heroku.com</a>></span> wrote:<br
/><blockquoteclass="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"><spanclass="">On Tue, Feb 10, 2015 at 4:21 PM, Robert Haas <<a
href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>>wrote:<br /> > Although the patch was described as
relativelyeasy to write, it never<br /> > went anywhere, because it *replaced* MD5 authentication with bcrypt,<br />
>which would be a big problem for existing clients.  It seems clear<br /> > that we should add something new and
notimmediately kill off what<br /> > we've already got, so that people can transition smoothly.  An idea I<br />
>just had today is to keep using basically the same system that we are<br /> > currently using for MD5, but with
astronger hash algorithm, like<br /> > SHA-1 or SHA-2 (which includes SHA-224, SHA-256, SHA-384, and<br /> >
SHA-512). Those are slower, but my guess is that even SHA-512 is not<br /> > enough slower for anybody to care very
much,and if they do, well<br /> > that's another reason to make use of the new stuff optional.<br /><br /></span>I
believethat a big advantage of bcrypt for authentication is the<br /> relatively high memory requirements. This
frustratesGPU based<br /> attacks.<br /><span class=""><font color="#888888"><br /><br /> --<br /> Peter Geoghegan<br
/></font></span><divclass=""><div class="h5"><br /><br /> --<br /> Sent via pgsql-hackers mailing list (<a
href="mailto:pgsql-hackers@postgresql.org">pgsql-hackers@postgresql.org</a>)<br/> To make changes to your
subscription:<br/><a href="http://www.postgresql.org/mailpref/pgsql-hackers"
target="_blank">http://www.postgresql.org/mailpref/pgsql-hackers</a><br/></div></div></blockquote></div><br
/></div><divclass="gmail_extra">There's also scrypt, which can be tuned for both memory and compute requirements.<br
/><br/>I don't think the "password storing best practices" apply to db connection authentication. So SHA256 (or any
othernon terribly broken hash) is probably fine for Pg.<br /><br /></div></div>