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

From David Garamond
Subject Re: Salt in encrypted password in pg_shadow
Date
Msg-id 413DFB69.8080302@zara.6.isreserved.com
Whole thread Raw
In response to Re: Salt in encrypted password in pg_shadow  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Salt in encrypted password in pg_shadow  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Tom Lane wrote:
> 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.

Many people use short and easy-to-guess passwords (remember we're not
talking about the superuser only here), so the dictionary attack can be
more effective than people think. And considering many people use the
same password for several things, Postgres could become one of the easy
sources to get/guess people's plaintext passwords from hacked machines.

At least Apache and Unix have been random-salting passwords for a while now.

However, I realize this will break the current MD5 hash, probably too
painful to do at the moment. Perhaps for the future, non-MD5 hash...

--
dave

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: ERROR: canceling query due to user request
Next
From: David Garamond
Date:
Subject: Restoring dump of multiuser databases