> Lessee ... we'll include a complete password hash table in a root kit,
> which will be used at a point where we've already managed to read
> pg_shadow but are somehow still lacking the ability to do anything else
> we could want to the database ... nope, not very compelling.
You are correct that the threat against the PostgreSQL installation itself
is not very compelling. However, take a look at the bigger picture:
People crack into systems and then try to use those systems to crack
into other systems. If you can make it harder to recover passwords
in the PostgreSQL system, then you've made it harder for attackers
to use those recovered passwords to attack other systems.
Think of the complete security environment, not just the security
of a particular PostgreSQL installation. Having random salts makes
it much harder for attackers to answer questions like "Does user X
have the same password in PostgreSQL installation 1 as he does in PostgreSQL
installation 2".
> Lessee ... we'll include a complete password hash table in a root kit,
> which will be used at a point where we've already managed to read
> pg_shadow but are somehow still lacking the ability to do anything else
> we could want to the database ... nope, not very compelling.
You are correct that the threat against the PostgreSQL installation itself
is not very compelling. However, take a look at the bigger picture:
People crack into systems and then try to use those systems to crack
into other systems. If you can make it harder to recover passwords
in the PostgreSQL system, then you've made it harder for attackers
to use those recovered passwords to attack other systems.
Think of the complete security environment, not just the security
of a particular PostgreSQL installation. Having random salts makes
it much harder for attackers to answer questions like "Does user X
have the same password in PostgreSQL installation 1 as he does in PostgreSQL
installation 2".
Regards,
David.
[ reply ]