Re: Salt in encrypted password in pg_shadow

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 <tgl@sss.pgh.pa.us> writes:
>
>
>
>>Greg Stark <gsstark@mit.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.
>
>
>