>> Just like Kryptonite was used to foil Superman, salt is usedto foil an attacker's rainbow table. Salt is simply acollection of random bits that are inputted into the hashingalgorithm along with the original plain text. Thepassword and the concatenated salt will be hashed and theoutput hash will be stored with the salt in the passworddatabase. Yes, the salts are stored in plain text. There's noneed to worry. First off, if the salts were encrypted, we'd haveto 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 anadded layer of encryption and decryption. Finally, the wholepoint of the salt is to prevent a rainbow table from attackingyour passwords. Lets say your password is Rochester, and thestored hash is abcd. In this rainbow table, abcd leads to thepassword Rochester. If your password was salted, the storedhash for Rochester-and-the-salt wouldn't be abcd, but let'ssay efgh. Efgh isn't found in this rainbow table, since thisrainbow table was generated without any salt. Therefore,efgh wouldn't lead to the password Rochester, and anattack with this rainbow table would be unsuccessful. Followthese rules and you'll be fine. Salts should be unique, not justin a database but worldwide. If a rainbow table is generatedwith a particular salt, at most it can attack one singlepassword. Since salts are different in each case, theyalso protect commonly used passwords, or those who use thesame password on several sites, by making all salted hashinstances for the same password different from each other. Saltsshould also be random and unpredictable so an attackercan't construct a small number of narrow rainbow tables basedon knowing, for instance, that the salt is based on the userID. Salts should be long. Since salts aren't memorized, they canmake the size of the rainbow table required for a successfulattack prohibitively large without imposing any burden onthe users. So now when you log into a system, your password,before it's hashed, is concatenated with a salt, thenit's hashed. Now the hash is compared to the stored hash inthe password database. Think back to the dictionary attackswe've talked about. Do you think salt would be good against aprecomputed dictionary file? If the file has precomputed hasheswithout salt, for sure now that file is worthless because all ofthose hashes were computed without any salt. What if thefile has plain text entries that will be hashed? Yes as well. Ifthe salts are different for every user, then the largedictionary file would need all of the salts applied to eachplain text before they're hashed. That could be thousandsor millions of salts that would need to be applied to each andevery entry in the dictionary file, making it not feasible forthe attackers. Since hashes will be different for users with thesame passwords, this prevents an attacker from using a leakedpassword-hash database to attack other accounts using the samepassword. However, when an attacker wants to break a singlepassword with a brute force or a dictionary attack, salts offerno protection since they are visible and a user's particularsalt can be added to the dictionary file for each entrywith ease. Salt is not meant to prevent a password from beingguessed but, rather, to prevent a leaked password database frombeing used in further attacks.
转载于:https://www.cnblogs.com/sec875/articles/10015932.html
相关资源：垃圾分类数据集及代码