Hi all;
With all due respect I generally side with Tom here.
Random salt values make sense in a few environments, for example, local
logins. They are designed to prevent someone from, say, copying the old
/etc/passwd or new /etc/shadow and then running an attack against the
passwords on it so that these passwords can be used to attack the
machine. This only works because you have a theoretical delay between
incorrect password attempts, so dictionary attacks directly are supposed
to be difficult to impliment. I say theoretically because a smart
attacker will use a program to open multiple telnet connections
simultaneously to try a large number of passwords at once.
Iirc, if PostgreSQL recieves a bad authentication attempt, it returns an
error and drops the connection. This is a double-edged sword
security-wise (allows for rapid dictionary attacks, but makes DoS a bit
less of a problem) and is a benefit performance-wise. So for the real
question: why would random salt values provide any security when it
would be less costly just to use a dictionary attack against account
itself? Given this model, it seems the only security benefit would be
that the attack Greg describes would be less likely to show up in the
logs. However, it could only work if the PostgreSQL instance is already
compromised, so this argument is somewhat moot. His argument seems to
be along the lines that the random salt in the /etc/shadow prevents root
from masquerading as any other user, which doesn't really work since
root can do this anyway. If an attacker can read pg_shadow, the fact
that the salt is not random is the least of your concerns.....
Best Wishes,
Chris Travers
Metatron Technology Consulting
Greg Stark wrote:
Tom Lane <tg*@sss.pgh.pa .us> writes:
Greg Stark <gs*****@mit.ed u> 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.
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
