Re: Salt in encrypted password in pg_shadow - Mailing list pgsql-general

From Tom Lane
Subject Re: Salt in encrypted password in pg_shadow
Date
Msg-id 2186.1094578607@sss.pgh.pa.us
Whole thread Raw
In response to Re: Salt in encrypted password in pg_shadow  (Richard Huxton <dev@archonet.com>)
Responses Re: Salt in encrypted password in pg_shadow  (David Garamond <lists@zara.6.isreserved.com>)
List pgsql-general
Richard Huxton <dev@archonet.com> writes:
> David Garamond wrote:
>> Consider someone who creates a long list of:
>> MD5( "postgres" + "aaaaaaaa" )
>> MD5( "postgres" + "aaaaaaab" )
>> MD5( "postgres" + "aaaaaaac" )

> But surely you have to store the random salt in pg_shadow too? Or am I
> missing something?

I think David is suggesting that the hypothetical attacker could gain
economies of scale in multiple attacks (ie, if he'd been able to steal
the contents of multiple installations' pg_shadow, he'd only need to
generate his long list of precalculated hashes once).  I think this is
too far-fetched to justify an authentication protocol change though.

Also, MD5 hashing is fast enough that I'm not sure the above is really
significantly cheaper than a straight brute-force attack, ie, you just
take your list of possible passwords and compute the hashes on the fly.
The hashes are going to be much longer than the average real-world
password, so reading in a list of hashes is going to take several times
as much I/O as reading the passwords --- seems to me that it'd be
cheaper just to re-hash each password.

            regards, tom lane

pgsql-general by date:

Previous
From: Alex Soto
Date:
Subject: Re: supressing NOTICE messages on Windows/cygwin only not working?
Next
From: Tom Lane
Date:
Subject: Re: [PERFORM] Table UPDATE is too slow