Unit 2: Password Cracking 2.1 Password Cracking Salt

>> Just like Kryptonite was used to foil Superman, salt is used
to foil an attacker's rainbow table. Salt is simply a
collection of random bits that are inputted into the hashing
algorithm along with the original plain text. The
password and the concatenated salt will be hashed and the
output hash will be stored with the salt in the password
database. Yes, the salts are stored in plain text. There's no
need to worry. First off, if the salts were encrypted, we'd have
to store a key somewhere. Now you have the same problem,
protecting that key. Secondly, if the salts were encrypted,
that would slow down the authentication process with an
added layer of encryption and decryption. Finally, the whole
point of the salt is to prevent a rainbow table from attacking
your passwords. Lets say your password is Rochester, and the
stored hash is abcd. In this rainbow table, abcd leads to the
password Rochester. If your password was salted, the stored
hash for Rochester-and-the-salt wouldn't be abcd, but let's
say efgh. Efgh isn't found in this rainbow table, since this
rainbow table was generated without any salt. Therefore,
efgh wouldn't lead to the password Rochester, and an
attack with this rainbow table would be unsuccessful. Follow
these rules and you'll be fine. Salts should be unique, not just
in a database but worldwide. If a rainbow table is generated
with a particular salt, at most it can attack one single
password. Since salts are different in each case, they
also protect commonly used passwords, or those who use the
same password on several sites, by making all salted hash
instances for the same password different from each other. Salts
should also be random and unpredictable so an attacker
can't construct a small number of narrow rainbow tables based
on knowing, for instance, that the salt is based on the user
ID. Salts should be long. Since salts aren't memorized, they can
make the size of the rainbow table required for a successful
attack prohibitively large without imposing any burden on
the users. So now when you log into a system, your password,
before it's hashed, is concatenated with a salt, then
it's hashed. Now the hash is compared to the stored hash in
the password database. Think back to the dictionary attacks
we've talked about. Do you think salt would be good against a
precomputed dictionary file? If the file has precomputed hashes
without salt, for sure now that file is worthless because all of
those hashes were computed without any salt. What if the
file has plain text entries that will be hashed? Yes as well. If
the salts are different for every user, then the large
dictionary file would need all of the salts applied to each
plain text before they're hashed. That could be thousands
or millions of salts that would need to be applied to each and
every entry in the dictionary file, making it not feasible for
the attackers. Since hashes will be different for users with the
same passwords, this prevents an attacker from using a leaked
password-hash database to attack other accounts using the same
password. However, when an attacker wants to break a single
password with a brute force or a dictionary attack, salts offer
no protection since they are visible and a user's particular
salt can be added to the dictionary file for each entry
with ease. Salt is not meant to prevent a password from being
guessed but, rather, to prevent a leaked password database from
being used in further attacks.

转载于:https://www.cnblogs.com/sec875/articles/10015932.html