问题描述
我已经阅读了许多有关此的问题，但是许多答案彼此矛盾，或者我听不懂.
I've read through many of the questions on SO about this, but many answers contradict each other or I don't understand.
您应该始终将密码存储为哈希，而不是纯文本.但是您应该在数据库中的哈希密码+盐旁边存储盐(每个用户唯一的盐).对我来说，这似乎不太聪明，因为有人无法访问数据库，无法找到名为Admin的帐户或其他名称，然后从中找出密码?
You should always store a password as a hash, never as plain text.But should you store the salt (unique for each user) next to the hashed password+salt in the database. This doesn't seem very clever to me as couldn't someone gain access to the database, look for says the account called Admin or whatever and then work out the password from that?
推荐答案
很多人在说停止彩虹表"，却没有解释彩虹表的作用或阻止彩虹表的原因.
A lot of people are saying "to stop rainbow tables" without explaining what rainbow tables do or why this stops them.
彩虹表是一种聪明的方法，可以预先计算大量的哈希并将其存储在比天真的需要的更少的内存中，您可以使用它们非常快速地反转哈希.诸如hash = md5(password)和hash = sha1(password)之类的裸函数表是常见的.
Rainbow tables are a clever way of precomputing a large number of hashes and storing them in less memory than would naively be required, and you can use them to very quickly reverse a hash. Tables for bare functions such as hash = md5(password) and hash = sha1(password) are common.
但是，可以为任何哈希函数生成它们，可以将其描述为output = f(input).如果对所有用户密码(例如hash = md5(salt+password))使用站点范围内的盐，则可以构造函数f，f(password) = md5(salt+password).因此，您可以为此功能生成彩虹表，这会花费很长时间，但随后会让您非常快速地破解数据库中的每个密码.
However, they can be generated for ANY hash function which can be described as output = f(input). If you use a site-wide salt for all user passwords, for example hash = md5(salt+password), you could construct a function f, f(password) = md5(salt+password). Therefore you could generate rainbow tables for this function, which would take a long time, but would then let you crack every single password in the database very rapidly.
如果每个密码的盐都不同，则无法生成将破解数据库中所有密码的彩虹表.您可以为每个用户生成一个新文件，但这将毫无意义-天真的暴力破解不会变慢.因此，为每个用户使用单独的盐可以阻止彩虹表攻击.
If the salt is different for each password, you can't generate a rainbow table that will crack all passwords in the database. You could generate a new one for every user but that would be pointless - naive brute-forcing would be no slower. So having a seperate salt for each user stops the rainbow tables attack.
有几种方法可以做到这一点.流行的方式包括:
There are several ways to do accomplish this. Popular ways include:
- 为每个用户单独存储的盐，与其他详细信息一起存储在数据库中:
hash = hashfunction(salt + password) - 全局盐和每个用户的一些唯一值:例如
hash = hashfunction(salt + password + user_id) - 全局盐和按用户使用的盐:
hash = hashfunction(global_salt + user_salt + password)
- A separate salt for each user, stored alongside their other details in the database:
hash = hashfunction(salt + password) - A global salt and some unique value per user:
hash = hashfunction(salt + password + user_id)for example - A global salt and a per-user salt:
hash = hashfunction(global_salt + user_salt + password)
使用全局盐可能会增加一些额外的复杂度来破解密码，因为它可能存储在数据库外部(例如，在代码中)，如果数据库遭到破坏，攻击者可能无法访问.从密码学上讲，我认为它不会增加太多，但是在实践中，它可能会使它们变慢.
Having a global salt could add a little extra complexity to cracking the passwords, as it could be stored outside of the database (in the code, for example) which attackers may not gain access to in the event of a database breach. Cryptographically I don't think it adds much, but in practice it could slow them down.
最后，回答您的实际问题:
与用户数据一起存储盐不会削弱哈希.哈希函数是单向的:给定密码的哈希，即使是未加盐的哈希，也很难找到该密码.盐析的动机不是使单个哈希更安全，而是使多个哈希的集合更安全.无盐散列的集合有多种攻击方式:
Storing the salt alongside the user data does not weaken the hash. Hash functions are one-way: Given the hash of a password, even an unsalted one, it is very difficult to find that password. The motivation behind salting is not to make an individual hash more secure, but to make the collection of multiple hashes more secure. There are several vectors of attack for a collection of unsalted hashes:
- 彩虹桌
- 散列常用密码(
123，password，god)并查看数据库中是否存在任何密码，然后破坏这些帐户 - 在数据库中查找相同的哈希，这意味着(可能)相同的密码
- Rainbow tables
- Hashing common passwords (
123,password,god) and seeing if any exist in the database, and then compromise those accounts - Look for identical hashes in the database, which means identical passwords (probably)
这篇关于盐，密码和安全性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！