From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Richard Huxton <dev(at)archonet(dot)com> |
Cc: | David Garamond <lists(at)zara(dot)6(dot)isreserved(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Salt in encrypted password in pg_shadow |
Date: | 2004-09-07 17:36:47 |
Message-ID: | 2186.1094578607@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Richard Huxton <dev(at)archonet(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-09-07 18:00:13 | Re: [PERFORM] Table UPDATE is too slow |
Previous Message | Alex Soto | 2004-09-07 17:27:40 | Re: supressing NOTICE messages on Windows/cygwin only not working? |