From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Salt in encrypted password in pg_shadow |
Date: | 2004-09-08 06:24:18 |
Message-ID: | 87llflnur1.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Greg Stark <gsstark(at)mit(dot)edu> writes:
> > However with a known salt you only have to store the 1,000 hashes with the
> > known salt. You could instead store a dictionary of 64 million password
> > guesses in the same gigabyte.
>
> This is still not responding to my original point though: if you know
> the salt that was used, you can try brute-force scan of a few thousand
> probable passwords in less CPU time than it will take to read a gigabyte
> of precomputed hashes. The fact that common passwords are much shorter
> than the fixed-size MD5 hashes works against you in a big way.
We must be talking past each other. The threat model salts are meant to defend
against is someone who has access to the data in pg_shadow for many users.
Without the salts or with salts you can predict beforehand you look up the
hash value in your precomputed dictionary using an index and instantaneously
get a working password.
Postgres's current method is in fact doing it wrong. Because the salt is
predictable for the "postgres" users it doesn't protect against the attack
above. If I knew I could get access to lots of pg_shadow's, say I work at an
off-site backup storage company, I could check each of them instantaneously
against a precomputed index of hundreds of thousands of guessable passwords.
The same attack against a well salted hash would require running the entire
battery of hashes against each client's password individually.
The reason I say the threat model doesn't apply is only because it's unlikely
that someone would have access to many postgres installs's pg_shadow. That's
the only situation where that attack would arise. (Or if a given install had
hundreds of users with the same initial letters I guess, but that also seems
rare)
But if you're not going to worry about that threat then salting is buying you
nothing anyways. If you're going to use a salt you may as well use one that
accomplishes what it's there for.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | juleni | 2004-09-08 06:36:24 | Starting and stopping database by JAVA |
Previous Message | Daniel Secomb | 2004-09-08 06:05:10 | ERROR: parser: unterminated quoted string |