我是否必须将盐与哈希放在同一列中？
因此，我很乐意使用每用户盐来散列我的用户的密码。不过，接受的答案中有一条建议：
不要使用单独的盐柱。
这对我来说没有意义。如果我只是连接哈希和盐并将它们放在同一列中，那么在语义上肯定相当于两个单独的列？在这种情况下，这只是默默无闻的安全，不是吗？
使用单独的列来存储盐会更容易（只要它是针对每个用户的）。我为什么不应该？
So, I'm cool with using a per-user salt to hash my users' passwords. However, there's one piece of advice in the accepted answer:
Do not use a separate column for the salt.
This doesn't make sense to me. If I'm just catenating the hash and salt and putting them in the same column, surely that's semantically equivalent to two separate columns? In which case, that's just security-by-obscurity, no?
It's easier to use a separate column to store the salt (as long as it's per-user). Why shouldn't I?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您要为每个用户存储随机盐，那并不重要。将盐+哈希存储在一列中，或者将盐和哈希存储在两列中。 就我个人而言，我会将其存储为单个列，因为您不太可能只检索盐或哈希值。此外，如果您更新盐，那么哈希值也需要更新，并且在更新哈希值时你不妨更新盐。从密码学的角度来看，这两种存储方法仍然同样有效。
我认为该评论所表明的（尽管效果很差）是另一种解决方案是从另一条每用户数据中派生盐，派生盐。
例如，采用用户名并将其传递给 PBKDF2 1000 多次迭代（实际上选择一个独特且不寻常的迭代次数更好 - 比如说 2137）。这需要攻击者不仅获得数据库的访问权限，还获得源代码的访问权限才能击败系统。
现在，如果攻击者可以完全访问密码表和密码表。源代码，您没有获得任何安全性，但是，如果攻击只能访问数据库（有限入侵），您就可以阻止攻击，或者至少使其变得更加困难。
派生盐实现中要考虑的另一个方面是攻击者是否能够创建用户帐户（开放注册系统）。如果任何人（包括你的攻击者）都可以创建一个帐户（例如在 stackoverflow 上），则派生盐的价值就会降低。为什么？攻击者可以对盐进行逆向工程，从而只能通过明文攻击访问数据库（攻击者知道自己的密码和其他详细信息）。
If you are going to store a random per user salt it doesn't really matter. Store salt+hash in one column or store salt and hash in two columns. Personally I would store it as a single column because it is unlikely you will ever be retrieving just salt or just the hash. Also if you update the salt then hash needs to be updated also and when updating the hash you might as well update the salt. Still either method of storage is equally valid from a cryptography standpoint.
I think what that comment was indicating (although poorly) is that an alternative solution is to derive the salt from another piece of per-user data, a derived salt.
As an example take username and pass it through 1000+ iterations of PBKDF2 (actually picking a unique and unusual number of iterations is better - say 2137). This would require attacker to gain access to not only the database but also your source code to defeat the system.
Now if the attacker has complete access to both password table & source code you have gained no security however if the attack has only access to the database (limited intrusion) you have stopped an attack or at least make it much more difficult.
Another aspect to consider in a derived salt implementation is if your attacker will be able to make a user account (open registration system). If anyone (including your attacker) can make an account (like say on stackoverflow) a derived salt is of less value. Why? Attacker can reverse engineer the salt and thus salt source with only access to the database via a plaintext attack (attacker knows his own password, and other details).
我认为该线程中第一个答案的第二部分（关于“动态盐”的部分）给了你一个像你期望的答案：生成一个随机的、每用户的盐并将其与散列密码一起存储。这正是 UNIX passwd（以及后来的影子）文件几十年来所做的事情。
该线程中关于盐到底是什么存在一些混乱。一些回复采用了非常笼统的定义，即“在执行单向哈希之前将任何已知文本混合到密码中”。在执行单向哈希之前混合已知文本和秘密文本有很多原因，显然在这种情况下对已知文本的处理将取决于算法。例如，请查看 http://en.wikipedia.org/wiki/CRAM-MD5 通过让用户使用服务器指定的“盐”对其进行哈希处理，从而完全避免用户通过网络发送密码。
I think the second part of the first answer (the part about "dynamic salt") in that thread gives you an answer like you expect: Generate a random, per-user salt and store that with the hashed password. This is exactly what UNIX passwd (and later shadow) files have done for decades.
There's some confusion in that thread about what exactly salt is. Some replies take a very general definition along the lines of "any known text mixed into a password before performing a one-way hash". There are lots of reasons to mix known text and secret text before performing a one-way hash, and obviously the treatment of the known text in such cases would depend on the algorithm. For an example, look at http://en.wikipedia.org/wiki/CRAM-MD5 which avoids having the user send their password over the network at all by having them hash it with a "salt" specified by the server.
安全答案是没关系。
数据库的答案是盐和哈希值是不同的数量，因此您最好将它们存储在不同的列中。如果您这样做，那么数据库可以说是标准化。
然而，对数据库进行非规范化以提高访问速度的情况并不少见 - 将散列和盐连接在同一列中就是非规范化的一个示例。
将盐和哈希分开的原因之一是您打算搜索它们中的一个或另一个。在我看来，这不太可能是您想要做的事情，所以继续将它们连接起来存储。
The security answer is that it doesn't matter.
The database answer is that the salt and the hash are different quantities, and so you should ideally store them in different columns. If you do this then the database can be said to be normalized.
However, it is not uncommon to denormalize a database to improve access speed - concatenating the hash and salt in the same column would be an example of denormalization.
One reason to keep the salt and hash separate would be that you envisage searching for one or other of them. It seems to me unlikely that this is something that you'd want to do, so go ahead and store them concatenated.