密码散列，盐和存储散列值 [英] Password hashing, salt and storage of hashed values

问题描述

假设你可以自由地决定如何将哈希密码存储在DBMS中。在这样一个方案中有明显的弱点吗？

要创建存储在DBMS中的哈希值，请执行以下操作：

• 作为盐的一部分，DBMS服务器实例唯一的值


• 另外，用户名作为盐的第二部分， li>
  
• 使用实际密码创建盐的连接


• 使用SHA-256算法对整个字符串进行散列，


• 并将结果存储在DBMS中。

这意味着任何想要碰撞的人都应该分别为每个用户名和每个DBMS服务器实例分别进行工作。我打算保持实际的哈希机制有些灵活，以允许使用新的 NIST 标准哈希算法（ SHA-3 ）。

DBMS服务器实例唯一的值不需要秘密 - 尽管如此不会随便泄露意图是确保如果有人在不同的DBMS服务器实例中使用相同的密码，则记录的哈希将会不同。同样，用户名不会是秘密的 - 只是密码正确。

首先有密码和用户名和唯一值是否有优势，还是三个数据来源的任何其他置换？或者交织字符串怎么样？

我需要添加（并记录）随机盐值（每个密码）以及上面的信息吗？ （优点：用户可以重新使用密码，但仍然可能会在数据库中记录不同的哈希。缺点：盐必须被记录，我怀疑这个优点显着胜过劣势。）

有很多相关的SO问题 - 这个列表不太可能是全面的：

• < a href =https://stackoverflow.com/questions/287517/encrypting-hashing-plain-text-passwords-in-database>数据库中加密/散列纯文本密码


• 为密码安全设置哈希和盐


• 隐藏盐的必要性散列


• 客户端MD5哈希与时间盐


• 简单密码加密


• 盐生成和开源软件


• 密码哈希：固定长度二进制字段或单字符串字段？

我认为这些问题的答案支持我的算法（虽然如果你只是使用随机盐，那么每个服务器的唯一值和用户名组件不太重要）。

解决方案

盐只需要随机和独特。它可以自由地知道，因为它不利于攻击者。许多系统将将明文盐存储在哈密码密码旁边的列中的数据库中。

盐有助于确保如果两个人（用户A和用户B）碰巧分享相同的密码是不明显的。没有每个密码的随机和唯一的盐，哈希值将是相同的，显然如果用户A的密码破解，那么用户B必须具有相同的密码。

它也有助于防止散列字典与已知密码匹配的攻击。例如彩虹表。

同时使用内置工作因子的算法也意味着，随着计算能力的增加，算法必须经过创建散列的工作也增加了。例如， bcrypt 。这就意味着暴力袭击的经济学无法维持。推测，创建已知哈希表是非常困难的，因为它们需要更长时间才能创建; 工作因素的变化将意味着需要建立更多的表。

Suppose you were at liberty to decide how hashed passwords were to be stored in a DBMS. Are there obvious weaknesses in a scheme like this one?

To create the hash value stored in the DBMS, take:

• A value that is unique to the DBMS server instance as part of the salt,
• And the username as a second part of the salt,
• And create the concatenation of the salt with the actual password,
• And hash the whole string using the SHA-256 algorithm,
• And store the result in the DBMS.

This would mean that anyone wanting to come up with a collision should have to do the work separately for each user name and each DBMS server instance separately. I'd plan to keep the actual hash mechanism somewhat flexible to allow for the use of the new NIST standard hash algorithm (SHA-3) that is still being worked on.

The 'value that is unique to the DBMS server instance' need not be secret - though it wouldn't be divulged casually. The intention is to ensure that if someone uses the same password in different DBMS server instances, the recorded hashes would be different. Likewise, the user name would not be secret - just the password proper.

Would there be any advantage to having the password first and the user name and 'unique value' second, or any other permutation of the three sources of data? Or what about interleaving the strings?

Do I need to add (and record) a random salt value (per password) as well as the information above? (Advantage: the user can re-use a password and still, probably, get a different hash recorded in the database. Disadvantage: the salt has to be recorded. I suspect the advantage considerably outweighs the disadvantage.)

There are quite a lot of related SO questions - this list is unlikely to be comprehensive:

• Encrypting/Hashing plain text passwords in database
• Secure hash and salt for PHP passwords
• The necessity of hiding the salt for a hash
• Clients-side MD5 hash with time salt
• Simple password encryption
• Salt generation and Open Source software
• Password hashes: fixed-length binary fields or single string field?

I think that the answers to these questions support my algorithm (though if you simply use a random salt, then the 'unique value per server' and username components are less important).

解决方案

The salt just needs to be random and unique. It can be freely known as it doesn't help an attacker. Many systems will store the plain text salt in the database in the column right next to the hashed password.

The salt helps to ensure that if two people (User A and User B) happen to share the same password it isn't obvious. Without the random and unique salt for each password the hash values would be the same and obviously if the password for User A is cracked then User B must have the same password.

It also helps protect from attacks where a dictionary of hashes can be matched against known passwords. e.g. rainbow tables.

Also using an algorithm with a "work factor" built in also means that as computational power increases the work an algorithm has to go through to create the hash can also be increased. For example, bcrypt. This means that the economics of brute force attacks become untenable. Presumably it becomes much more difficult to create tables of known hashes because they take longer to create; the variations in "work factor" will mean more tables would have to be built.

这篇关于密码散列，盐和存储散列值的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！