是“双散列”一个密码比刚刚哈希一次安全？ [英] Is "double hashing" a password less secure than just hashing it once?
问题描述
在存储之前对密码进行两次哈希的操作比只是哈希处理一次还要安全吗？
我在说的是：
$ hashed_password = hash（hash（$ plaintext_password））;
而不仅仅是：
$ hashed_password = hash（$ plaintext_password）;
如果不够安全，你能提供一个很好的解释/ p>
此外，散列函数是否有所不同？如果你混合使用md5和sha1（例如）而不是重复相同的哈希函数，它会有什么不同吗？
注意1：当我说double hashing m谈到哈希一个密码两次，以试图使它更模糊。我不是在谈论解决冲突的技巧。
注意2：我知道我需要添加一个随机盐，以确保安全。问题是使用相同的算法散列两次是否有帮助或伤害散列。
不安全
不，多个哈希值不安全;它们是安全密码使用的重要组成部分。
迭代哈希值会增加攻击者在其候选项列表中尝试每个密码所需的时间。
简单迭代不够
仅将散列输出链接到输入对于安全性是不够的。迭代应该在保留密码熵的算法的上下文中进行。幸运的是，有几个已发布的算法已经经过足够的仔细检查，以确保他们的设计。
一个好的密钥导出算法，如PBKDF2注入密码到每一轮哈希，减少对散列输出中的冲突的关注。 PBKDF2可以直接用于密码验证。 Bcrypt跟随密钥推导与加密步骤;如果发现反向密钥推导的快速方法，攻击者仍然必须完成已知明文攻击。
如何破解密码
存储的密码需要防止脱机攻击。如果密码未被盐化，则可以使用预先计算的字典攻击（例如，使用彩虹表）来破解密码。否则，攻击者必须花时间为每个密码计算一个散列，并查看它是否与存储的散列匹配。
所有密码的可能性不大。攻击者可能会详尽地搜索所有短密码，但他们知道，他们的暴力成功机会与每个额外的字符急剧下降。相反，他们使用最可能的密码的有序列表。它们以password123开头，并进入较不常用的密码。
假设攻击者名单很长，有100亿候选人;假设桌面系统每秒可以计算100万个散列。如果只使用一次迭代，攻击者可以测试她的整个列表小于三个小时。但是如果只使用2000次迭代，那么时间延长到近8个月。为了打败一个更复杂的攻击者，一个能够下载程序的程序，可以挖掘他们的GPU的力量，例如—你需要更多的迭代。
多少钱？
要使用的迭代次数是安全和用户体验之间的折衷。攻击者可以使用的专用硬件很便宜，但它仍然可以每秒执行数亿次迭代。 攻击者的系统的性能决定了在多次迭代后破解密码需要多长时间。但是你的应用程序不太可能使用这个专门的硬件。可以在不加重用户的情况下执行多少次迭代取决于您的系统。
您可以让用户等待额外的¾第二左右。描述您的目标平台，并使用尽可能多的迭代，你可以负担得起。我已测试的平台（移动设备上的一个用户或服务器平台上的许多用户）可以轻松地支持 PBKDF2 ，介于60,000到120,000次迭代之间，或 bcrypt ，成本系数为12或13.
更多背景
阅读PKCS＃5对于盐和迭代在哈希中的作用的权威信息。即使PBKDF2用于从密码生成加密密钥，它也可以作为密码验证的单向散列。 bcrypt的每次迭代都比SHA-2哈希更昂贵，所以你可以使用更少的迭代，但是想法是一样的。 Bcrypt还通过使用派生密钥加密众所周知的纯文本，超越了大多数基于PBKDF2的解决方案。所得到的密文与一些元数据一起存储为散列。
这是我写的关于这个主题的其他答案：
Is hashing a password twice before storage any more or less secure than just hashing it once?
What I'm talking about is doing this:
$hashed_password = hash(hash($plaintext_password));
instead of just this:
$hashed_password = hash($plaintext_password);
If it is less secure, can you provide a good explanation (or a link to one)?
Also, does the hash function used make a difference? Does it make any difference if you mix md5 and sha1 (for example) instead of repeating the same hash function?
Note 1: When I say "double hashing" I'm talking about hashing a password twice in an attempt to make it more obscured. I'm not talking about the technique for resolving collisions.
Note 2: I know I need to add a random salt to really make it secure. The question is whether hashing twice with the same algorithm helps or hurts the hash.
Hashing a password once is insecure
No, multiple hashes are not less secure; they are an essential part of secure password use.
Iterating the hash increases the time it takes for an attacker to try each password in their list of candidates. You can easily increase the time it takes to attack a password from hours to years.
Simple iteration is not enough
Merely chaining hash output to input isn't sufficient for security. The iteration should take place in the context of an algorithm that preserves the entropy of the password. Luckily, there are several published algorithms that have had enough scrutiny to give confidence in their design.
A good key derivation algorithm like PBKDF2 injects the password into each round of hashing, mitigating concerns about collisions in hash output. PBKDF2 can be used for password authentication as-is. Bcrypt follows the key derivation with an encryption step; that way, if a fast way to reverse the key derivation is discovered, an attacker still has to complete a known-plaintext attack.
How to break a password
Stored passwords need protection from an offline attack. If passwords aren't salted, they can be broken with a pre-computed dictionary attack (for example, using a Rainbow Table). Otherwise, the attacker must spend time to compute a hash for each password and see if it matches the stored hash.
All passwords are not equally likely. Attackers might exhaustively search all short passwords, but they know that their chances for brute-force success drop sharply with each additional character. Instead, they use an ordered list of the most likely passwords. They start with "password123" and progress to less frequently used passwords.
Let's say an attackers list is long, with 10 billion candidates; suppose also that a desktop system can compute 1 million hashes per second. The attacker can test her whole list is less than three hours if only one iteration is used. But if just 2000 iterations are used, that time extends to almost 8 months. To defeat a more sophisticated attacker—one capable of downloading a program that can tap the power of their GPU, for example—you need more iterations.
How much is enough?
The number of iterations to use is a trade-off between security and user experience. Specialized hardware that can be used by attackers is cheap, but it can still perform hundreds of millions of iterations per second. The performance of the attacker's system determines how long it takes to break a password given a number of iterations. But your application is not likely to use this specialized hardware. How many iterations you can perform without aggravating users depends on your system.
You can probably let users wait an extra ¾ second or so during authentication. Profile your target platform, and use as many iterations as you can afford. Platforms I've tested (one user on a mobile device, or many users on a server platform) can comfortably support PBKDF2 with between 60,000 and 120,000 iterations, or bcrypt with cost factor of 12 or 13.
More background
Read PKCS #5 for authoritative information on the role of salt and iterations in hashing. Even though PBKDF2 was meant for generating encryption keys from passwords, it works well as a one-way-hash for password authentication. Each iteration of bcrypt is more expensive than a SHA-2 hash, so you can use fewer iterations, but the idea is the same. Bcrypt also goes a step beyond most PBKDF2-based solutions by using the derived key to encrypt a well-known plain text. The resulting cipher text is stored as the "hash," along with some meta-data. However, nothing stops you from doing the same thing with PBKDF2.
Here are other answers I've written on this topic:
这篇关于是“双散列”一个密码比刚刚哈希一次安全？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
