加盐的目的是什么？
在 Linux 系统中，密码使用 MD5 哈希值存储。为什么使用“盐”更能保护系统呢？特别是，我想明确以下两个
- 盐据说存储在 带有哈希值的明文，那么如何 它可以防止攻击者 攻击者知道盐值。 （攻击者可以是系统 管理员本人可以检查
/etc/shadow。 - 如果盐是随机生成的 每次，系统怎么能 比较哈希值以验证 用户？
例如，用户A有用户salt s1，生成h1； h1 = md5(密码.s1);。 下一次，它使用 salt s2，系统必须生成不同的哈希值，h2 = md5(password.s2)。既然h1不等于h2，那么系统如何验证用户的身份呢？
In a Linux system, passwords are stored using an MD5 hash. Why can the usage of "salt" protect the system more? Particularly, I want to make clear the following two
- The salt is said to be stored in
clear text with the hash, then how
it can prevent the attacker when the
attacker knows the salt value.
(Attacker can be the system
administrator himself who can check/etc/shadow. - If the salt is generated randomly
everytime, how can the system
compare the hash to authenticate the
user?
For example, User A has user salt s1 and generate h1; h1 = md5(password.s1);.
The next time, it uses salt s2 and the system must generate a different hash, h2 = md5(password.s2). Since h1 is not equal to h2, how can the system authenticate the user?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如您所知，MD5 是一个哈希值，因此如果您给它一个输入，例如“PASSWORD”，您将得到一个唯一的（希望如此 - 但现在 MD5 有冲突）输出，例如“3DE2AF...”。
现在，如您所知，很难直接反转它，直到有人想到......等等，为什么我不预先生成可哈希值的所有可能组合，直到我可以反转哈希。这称为彩虹表。
salt 的目的是将任意随机数据添加到正在散列的字符串中，以便增加散列输入的长度。这意味着仅期望将密码输入反转为哈希的一般彩虹表将无法工作。当然，彩虹表只是反向查找，您可以简单地生成一个彩虹表来补偿所有可能的密码+盐输出。这就是长度的增加发挥作用的地方；由于反转哈希的性质，用于为很长的哈希输入生成反转的磁盘空间很快就变得不可行。 6-8 个字符的字母数字彩虹表已经有几 GB；增加长度和字符类别，您就可以开始以 10GB 的倍数进行通话。
当然，如果您使用“PASSWORD”加盐并对“PASSWORD”进行哈希处理，那么您正在对“PASSWORDPASSWORD”进行哈希处理，这并没有那么安全，因此盐的选择也很重要。理想情况下，您应该对每个散列字符串使用随机盐，但当然，您需要知道它是什么。一种常见的技术是从用户名或本例特有的其他一些属性中派生出盐。添加任意数据本身并没有什么用处；现在，拥有用户确定的盐数据会增加额外的复杂性，这意味着需要彩虹表来针对每个用户进行专门搜索。你让这件事变得越困难，就需要越多的计算能力。这就是战斗的所在。
然而，有一些现代技术。我不是专家，所以我无法告诉你它们有多安全，但它们值得一提。这个概念是慢散列。基本上，通过复合哈希函数，您需要花费一些时间来计算每个哈希值。因此，现在每个用户检查密码的能力都会为您希望检查的每个密码添加固定的时间。如果你进行暴力破解，那就是坏消息(tm)。同样，如果系统设计良好，如果没有捷径（这可能等同于弱点），那么为慢速哈希函数生成彩虹表也应该需要一段时间。
在此处编辑更多详细信息。第一个参见
crypt()这方面的例子。 @CodeInChaos 引用了PBKDF2 构成 PKCS#5 的一部分。较新的开发是 scrypt。正如我所说，我不是密码分析专家。对于后一个例子，我对其适用性没有特别的专业知识，我只是向您展示事情的发展方向。
编辑2澄清了我写的盐 - 我想我之前围绕磁盘空间的关键问题进行了讨论。
MD5 is a hash as you know, so if you give it an input, like 'PASSWORD', you get a unique (hopefully - however MD5 has collisions these days) output, like '3DE2AF...'.
Now, as you know, it's quite hard to directly reverse that, until somebody thought... wait, why don't I pre-generate all the possible combinations of hashable values until I can reverse the hash. This is called a rainbow table.
The purpose of a salt is to add arbitrary random data to the string being hashed, such that you increase the length of input to hash. This means general rainbow tables that expect to reverse just a password input to a hash won't work. Of course, rainbow tables being just reverse lookups, you could simply generate a rainbow table to compensate for all the possible password+salt outputs. This is where the increase in length comes into its own; because of the nature of reversing hashes, the disk space to generate reverses for very long hash inputs soon becomes infeasible. Alphanumeric rainbow tables for 6-8 characters are already a couple of Gigabytes; increase the length and character classes and you start to talk in multiples of 10GB.
Of course, if you're salting with 'PASSWORD' and you hash 'PASSWORD' you're hashing 'PASSWORDPASSWORD' which isn't that much more secure, so the choice of salt is important too. Ideally, you should use a random salt with each hashed string, but of course, you need to know what it is. A common technique is to derive a salt from the username or some other property unique to this case. Adding arbitrary data isn't in itself useful; having user-determined salt data now adds an additional level of complexity, meaning rainbow tables are needed with specialised searches for each user. The more you make this difficult, the more computational power is needed. That's where the battle is.
However, there are some modern techniques. I am not an expert, so I can't tell you how secure these are, but they are worth a mention. The concept is slow hashing. Basically, through compound hash functions you make it take a while to compute each hash. As such, the ability for each user to check the password now has a constant amount of time added for each password you wish to check. If you're bruteforcing, that is Bad News(tm). Similarly, if the system is well designed, if there are no shortcuts (which probably equate to weaknesses) then generating a rainbow table for a slow hash function should also take a while.
Edit more detail here. See
crypt()for the first example of this. @CodeInChaos has referenced PBKDF2 which forms part of PKCS#5. A newer development is scrypt.As I say, I'm not an expert cryptanalyst. On the latter example, I have no particular specialist knowledge as to its suitability, I'm merely showing you where things are headed.
Edit 2 Clarified my write up of salt - I think I danced around the key issue of disk space before.
您可以通过暴力破解简单的哈希算法。
如果您使用常用词作为密码，则某些预构建表（例如 rainbow 表）可能包含它们。这就是大多数算法多次调用哈希函数的原因：
使用盐可以为生成的密码提供更多的随机性，从而使其更不易被猜测。它包括在过程中添加一段随机字符串
You can reverse a simple hash algorithm by brute force.
If you are using a common word for passwords, some prebuild tables (like rainbow ones) might contain them. That's why most algorithms call the hash function several times:
Using salt gives a lot more of randomness to the generated password and thus make it less guessable. It consists of adding a random piece of string in the process
原因之一可能是，如果两个人在不知情的情况下使用相同的密码，他们将生成相同的 MD5。其中一个人可以看到 /etc/shadow 并猜测其他人的密码。
现在，在每个密码中添加盐后，即使相同的密码也会生成不同的哈希值。
One reason could be, if two people use same password unknowingly they will generate same MD5. One of them can just see /etc/shadow and guess other guys password.
Now with salt added to each password, even same passwords generate different hashes.
当您加密数据时，它仍然可能受到 bruce-force 攻击 和 彩虹攻击。在加盐过程中，您会在加密数据的末尾添加一些额外的位。因此攻击者无法正确获取原始数据。
When you encrypt data it can be still attacked by bruce-force attacks and rainbow attacks. In salting, at the end of the encrypted data you add some additional bits. So the attacker cannot get the original data properly.