Re: Salt in encrypted password in pg_shadow

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