Re: Salt in encrypted password in pg_shadow

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Steve Atkins <steve(at)blighty(dot)com> writes:
> > A random salt stored with the hashed password increases the storage
...
> [ raised eyebrow... ] It is not immediately obvious that a factor of
> 2^16 makes the difference between feasible and infeasible. As
> counterexamples, if it would otherwise take you one microsecond to break
> the password, 64 milliseconds isn't going to scare you; if it would
> otherwise take you a century to break the password, raising it to
> 64k centuries isn't going to make for a very meaningful improvement in
> security either.

*Storage* requirements. There's a pretty big range in the middle where the
extra 2^16 does make the difference.

The entire premise of cryptographic hashes after all depends on the assumption
that you cannot simply store an index of every possible hash value with the
plain-text that generated it.

That's only true if the number of plain-texts of concern is large enough to
make storing the hash value of each impractical. That's not true for human
chosen guessable passwords.

Now it's true that if you only want to try the top 1,000 guessable passwords
and you store a dictionary of all those with all 2^16 possible salts then it
requires only a gigabyte of storage. Perhaps a four character random salt
would make more sense.

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.

There's no question using a predictable salt is bad idea, postgres may as well
have not bothered salting at all. But realistically it seems kind of
irrelevant. It seems pretty unlikely that someone will gain access to
pg_shadow on many postgres installs which is the only way a dictionary attack
becomes a worry.

pg_shadow is not a public /etc/passwd like on a traditional unix machine where
I first saw salted crypt strings and it doesn't have hundreds or thousands of
entries like a public unix machine (at least not with predictable salts). The
threat model just doesn't apply.

--
greg