我应该使用什么算法将密码哈希到我的数据库中？

Question

是否有可用的任何并非易碎？

Answer 1

  

2008年的答案现在已经过时了。 SHA（所有变种）现在都很容易破解，现在（截至2013年1月）最佳做法是使用键拉伸哈希（如PBKDF2）或理想情况下是RAM密集型（如Bcrypt）并且也添加每用户盐。

     

第2,3和4点仍值得关注。

     

有关详情，请参阅IT Security SE site。

---

2008年原创回答：

1. 使用经过验证的算法。 SHA-256在数据库中使用了64个字符，但是列上的索引没有问题，并且它是经过验证的哈希值，比MD5和SHA-1更可靠。它也作为标准安全套件的一部分在大多数语言中实现。但是，如果使用SHA-1，请不要感觉不好。

2. 不要只是哈希密码，还要在其中加入其他信息。您经常使用“username：password：salt”或类似的哈希值，而不仅仅是密码，但如果您使用此密码，则会更难以运行字典攻击。

3. 安全是一个艰难的领域，不要以为你可以发明自己的算法和协议。

4. 不要写日志，如“[AddUser] Hash of GeorgeBush：Rep4Lyfe：ASOIJNTY是xyz”

Answer 2

加密和密码存储的第一条规则是“不要自己发明”，但是如果你必须在这里绝对最低限度，你必须做任何表面的安全：

基本规则：

1. 永远不要存储纯文本密码（这意味着您永远不能显示或传输它。）
2. 永远不要通过不安全的行（纯文本，编码或散列）传输存储的密码表示。
3. 速度是你的敌人。
4. 随着硬件和密码分析的改进，定期重新分析并改进您的流程。
5. 密码学和流程是解决方案的非常小的部分。
6. 故障点包括：存储，客户端，传输，处理，用户，法律保证，入侵和管理员。

步骤：

1. 强制执行一些合理的最低密码要求。
2. 经常更改密码。
3. 使用您可以获得的最强哈希值 - 这里建议使用 SHA-256 。
4. 将密码与固定盐相结合（整个数据库都相同）。
5. 将上一步的结果与存储并附加到此记录的唯一盐（可能是用户名，记录ID，guid，长随机数等）相结合。
6. 多次运行哈希算法 - 类似1000次以上。理想情况下，每次使用前一个哈希包含不同的盐。速度是你的敌人，多次迭代会降低速度。每次经常加倍迭代（这需要捕获一个新的哈希 - 下次更改密码时再做。）

哦，除非您运行SSL或其他线路安全性，否则不要以纯文本形式传输密码。如果您只是将客户端的最终哈希值与存储的哈希值进行比较，则不允许以纯文本格式传输。您需要向客户端发送一个nonce（使用过一次的数字）并让它们用它们生成的哈希（使用上面的步骤）散列哈希，然后它们会发送给你。在服务器端，您运行相同的过程，并查看两次哈希是否匹配。然后处置它们。有一种更好的方法，但这是最简单的方法。

Answer 3

CodingHorror去年有一篇很棒的文章

http://www.codinghorror.com/blog/archives/000953.html

文章末尾的建议是BCrypt

Answer 4

上述算法是加密安全散列算法（但MD5今天不被认为是安全的）。

然而，有些算法是专门为从密码派生密钥而创建的。这些是key derivation functions。它们设计用于对称密码，但它们也适用于存储密码。例如PBKDF2使用salt，大量迭代和良好的哈希函数。如果你有一个库，实现它的是什么（例如.NET），我认为你应该考虑它。

Answer 5

使用强大的加密哈希函数（如MD5或SHA1），但要确保使用好的salt，否则您将受到rainbow table攻击。

Answer 6

将unique salt添加到哈希密码值（将盐值存储在数据库中）。当unique salt is used使用比SHA1或MD5更安全的算法的好处并不是必需的时候（在这一点上它是一个渐进的改进，而使用盐是一个巨大的改进）。

Answer 7

2013年1月更新

最初的答案是从2008年开始，过去5年来情况有所改变。随时可用的云计算和功能强大的并行处理器显卡意味着密码最多可达8或9个字符，因为MD5或SHA1现在可以轻松破解。

现在需要长盐，就像SHA512更难实现。

但是，所有SHA变体哈希都是为通信加密而设计的 - 在每条消息都被加密的情况下来回传递消息，因此它们被设计为快速。

在密码哈希世界中，这种设计是一个很大的缺点，因为散列越快，生成大量哈希所需的时间就越少。

像SHA512这样的快速哈希可以生成数百万甚至数十亿次。投入廉价的并行处理，密码的每一种可能的排列都是绝对必要的。

键拉伸是解决这个问题的一种方法。密钥拉伸算法（如PBKDF2）应用更快的哈希（如SHA512）数千次，通常导致哈希生成花费1/5秒左右。登录的人不会注意到，但如果你每秒只能产生5次哈希，那么暴力攻击会更加困难。

其次总是是每用户随机盐。这可以随机生成为哈希的第一个 n 字节（然后在构建要比较的哈希值之前将其去除并添加到要检查的密码文本中）或作为额外的DB列。< / p>

所以：

  

我应该使用什么算法将密码哈希到我的数据库中？

• 键拉伸以减慢哈希生成速度。我可能会选择PBKDF2。

• 每用户盐意味着每个用户都有新的攻击，有些工作会弄清楚如何获取盐。

计算能力和可用性呈指数增长 - 这些规则有可能在未来4年再次发生变化。如果您需要面向未来的安全性，我会调查bcrypt / scrypt样式哈希 - 这些采用较慢的键扩展算法并添加一个使用大量RAM来生成哈希的步骤。使用如此多的RAM会降低廉价并行处理器的效率。

2008年9月原创（留待评论有意义）

MD5 +盐或SHA1 +盐并非“易碎” - 大多数黑客都依赖于巨大的彩虹表，而这些对于[update, now they are]盐变得不那么有用。

MD5 +盐是一个相对较弱的选择，但它不会轻易被打破[update, now it is very easy to break]。

SHA2一路上升到512--用随时可用的套件[update, pretty easy up to 9 char passwords now]进行破解是不可能的 - 尽管我确信某个军事掩体中有一个Cray可以做到{{1} }}

Answer 8

MD5或SHA与每个条目的随机生成的盐值组合

Answer 9

如前所述，这里不应使用简单的哈希算法，原因如下：

http://arstechnica.com/security/2012/08/passwords-under-assault/

所以请使用其他内容，例如http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx

Answer 10

所有散列算法都容易受到“字典攻击”的攻击。这只是攻击者拥有一个非常大的可能密码字典的地方，并且他们将所有密码都哈希。然后，他们会查看是否有任何哈希值与他们想要解密的密码的哈希值相匹配。这种技术可以轻松测试数百万个密码。这就是您需要避免任何可远程预测的密码的原因。

但是，如果你愿意接受字典攻击的威胁，MD5和SHA1都会绰绰有余。 SHA1更安全，但对于大多数应用程序来说，这确实不是一个重大改进。

Answer 11

MD5 / SHA1哈希都是不错的选择。 MD5略弱于SHA1。