|
If the same SALT is used for many passwords on a Linux server, in what way is that a security risk? Does the mean, that a user (which can change his own password) can calculate other users passwords? Or is brute forcing a rainbow table still required? |
|||
|
|
|
A constant salt (or not using any salt) allows to do the same brute-force or dictionary attack on many passwords at once, instead of only at one at the same time. So you'll get an earlier "first match", and more matches at all for the same amount of work. If the attacker wants a specific user's password, it is not faster at all (other than allowing precomputation of a hash→password table). Though if this attacked user has the same password with another user, this shows up, and a social (i.e. non-cryptographic) attack on this other user might be doable. |
|||
|
|
|
If two passwords match, e.g. because a user has multiple accounts and use the same password for all, this can easily be spotted if a constant "salt" is used. Another way of looking at it is that a hash function that is applied to passwords with a constant salt, is equivalent to using a modified hash function without salt. In the case of the MD and SHA family of hash functions, you get such a modified hash function by modifying the initial state, round constants, round functions and message expansion. |
|||||||
|
