php - PHP 密码的安全散列和盐

Question

目前据说 MD5 是部分不安全的。考虑到这一点，我想知道使用哪种机制来保护密码。

这个问题，Is “double hashing” a password less secure than just hashing it once?
表明多次散列可能是一个好主意，而 How to implement password protection for individual files?建议使用盐。

我正在使用 PHP。我想要一个安全快速的密码加密系统。将密码散列一百万次可能更安全，但也更慢。如何在速度和安全之间取得良好的平衡？另外，我希望结果具有恒定数量的字符。

散列机制必须在 PHP

中可用

一定是安全的

它可以使用盐(在这种情况下，所有盐都同样好？有什么方法可以生成好的盐？)

另外，我是否应该在数据库中存储两个字段(例如，一个使用 MD5，另一个使用 SHA)？它会让它更安全还是更不安全？

如果我不够清楚，我想知道使用哪个散列函数以及如何选择一个好的盐以获得安全和快速的密码保护机制。

不完全涵盖我的问题的相关问题:

What's the difference between SHA and MD5 in PHP
Simple Password Encryption
Secure methods of storing keys, passwords for asp.net
How would you implement salted passwords in Tomcat 5.5

Answer 1

DISCLAIMER: This answer was written in 2008.

Since then, PHP has given us password_hash and password_verify and, since their introduction, they are the recommended password hashing & checking method.

The theory of the answer is still a good read though.

TL; 博士

不要

不要限制用户可以输入的密码字符。只有白痴才会这样做。

不要限制密码的长度。如果你的用户想要一个带有 supercalifragilisticexpialidocious 的句子，不要阻止他们使用它。

不要在密码中删除或转义 HTML 和特殊字符。

永远不要以纯文本形式存储您的用户密码。

切勿通过电子邮件将密码发送给您的用户，除非他们丢失了密码，并且您发送了一个临时密码。

永远不要以任何方式记录密码。

永远不要用 SHA1 散列密码或 MD5 甚至 SHA256! Modern crackers可以超过 60 和 1800 亿哈希/秒(分别)。

不要混用bcrypt and with the raw output of hash() , 使用十六进制输出或 base64_encode 它。 (这适用于任何可能包含流氓 \0 的输入，这会严重削弱安全性。)

DOS

尽可能使用 scrypt；如果不能，请使用 bcrypt。

如果您不能使用 bcrypt 或 scrypt，请使用 PBKDF2 和 SHA2 哈希。

当数据库受到威胁时重置每个人的密码。

实现合理的 8-10 个字符的最小长度，此外还需要至少 1 个大写字母、1 个小写字母、一个数字和一个符号。这将提高密码的熵，从而使其更难破解。 (有关一些辩论，请参阅“什么是好的密码？”部分。)

为什么要散列密码？

散列密码背后的目标很简单:通过破坏数据库来防止对用户帐户的恶意访问。因此，密码散列的目标是通过花费太多时间或金钱来计算纯文本密码来阻止黑客或破解者。时间/成本是您武器库中最好的威慑力量。

您需要对用户帐户进行良好、健壮的散列的另一个原因是给您足够的时间来更改系统中的所有密码。如果您的数据库遭到破坏，您将需要足够的时间至少将系统锁定，如果不是更改数据库中的每个密码。

Jeremiah Grossman，Whitehat Security 首席技术官， stated on White Hat Security blog在最近的密码恢复后需要蛮力破解他的密码保护:

Interestingly, in living out this nightmare, I learned A LOT I didn’t know about password cracking, storage, and complexity. I’ve come to appreciate why password storage is ever so much more important than password complexity. If you don’t know how your password is stored, then all you really can depend upon is complexity. This might be common knowledge to password and crypto pros, but for the average InfoSec or Web Security expert, I highly doubt it.

(强调我的。)

什么才是好的密码？

Entropy . (并不是说我完全赞同兰德尔的观点。)

简而言之，熵是密码内的变化量。当密码仅为小写罗马字母时，即只有 26 个字符。那变化不大。字母数字密码更好，有 36 个字符。但允许大小写，带符号，大约是 96 个字符。这比只是字母要好得多。一个问题是，为了让我们的密码令人难忘，我们插入了模式——这减少了熵。哎呀!

密码熵是 approximated容易地。使用全范围的 ascii 字符(大约 96 个可键入的字符)产生每个字符 6.6 的熵，对于 future 的安全来说，8 个字符的密码仍然太低(52.679 位的熵)。但好消息是:更长的密码和带有 unicode 字符的密码确实增加了密码的熵，使其更难破解。

在 Crypto StackExchange 上有更长的关于密码熵的讨论。地点。一个好的谷歌搜索也会出现很多结果。

在我与@popnoodles 交谈的评论中，他指出执行 X 长度的密码策略，其中包含 X 个字母、数字、符号等，实际上可以通过使密码方案更可预测来减少熵。我同意。随机性，尽可能真正的随机性，始终是最安全但最不令人难忘的解决方案。

据我所知，制作世界上最好的密码是 Catch-22。要么它不令人难忘、太可预测、太短、太多 unicode 字符(在 Windows/Mobile 设备上难以输入)、太长等等。没有密码对我们的目的来说真的足够好，所以我们必须像保护它们一样保护它们在诺克斯堡。

最佳实践

Bcrypt 和 scrypt是当前的最佳实践。 Scrypt及时会比 bcrypt 更好，但它尚未被 Linux/Unix 或网络服务器视为标准，并且尚未发布对其算法的深入评论。但是，该算法的 future 看起来确实很有希望。如果您正在使用 Ruby，有一个 scrypt gem这将帮助你，Node.js 现在有它自己的 scrypt包裹。您可以通过 Scrypt 在 PHP 中使用 Scrypt。扩展名或 Libsodium扩展(两者都在 PECL 中可用)。

我强烈建议阅读 crypt function 的文档。如果你想了解如何使用 bcrypt，或者想找一个 good wrapper或使用类似 PHPASS 的东西对于更传统的实现。我建议至少 12 轮 bcrypt，如果不是 15 到 18。

当我了解到 bcrypt 只使用河豚的 key 时间表，并且具有可变成 native 制时，我改变了使用 bcrypt 的想法。后者让您通过增加河豚已经很昂贵的 key 时间表来增加暴力破解密码的成本。

平均做法

我几乎无法想象这种情况了。 PHPASS支持 PHP 3.0.18 到 5.3，因此它几乎可以用于所有可以想象的安装——如果您不确定您的环境是否支持 bcrypt，应该使用它。

但是假设您根本不能使用 bcrypt 或 PHPASS。然后怎样呢？

尝试实现 PDKBF2与 maximum number of rounds您的环境/应用程序/用户感知可以容忍。我建议的最低数量是 2500 轮。另外，请确保使用 hash_hmac()如果可以使操作更难重现。

future 实践

PHP 5.5 中的一个 full password protection library这消除了使用 bcrypt 的任何痛苦。虽然我们大多数人在最常见的环境中都坚持使用 PHP 5.2 和 5.3，尤其是共享主机，但@ircmaxell 已经构建了一个 compatibility layer对于即将推出的向后兼容 PHP 5.3.7 的 API。

密码学回顾和免责声明

实际破解散列密码所需的计算能力并不存在。计算机“破解”密码的唯一方法是重新创建密码并模拟用于保护密码的散列算法。散列的速度与其暴力破解的能力呈线性关系。更糟糕的是，大多数哈希算法都可以轻松并行化以更快地执行。这就是为什么像 bcrypt 和 scrypt 这样昂贵的方案如此重要的原因。

您不可能预见所有威胁或攻击途径，因此您必须尽最大努力保护您的用户 前台 .如果你不这样做，那么你甚至可能会错过你被攻击的事实，直到为时已晚……而且你要承担责任。为了避免这种情况，首先要表现出偏执。攻击您自己的软件(内部)并尝试窃取用户凭据，或修改其他用户的帐户或访问他们的数据。如果您不测试系统的安全性，那么除了您自己之外，您不能责怪任何人。

最后:我不是密码学家。我所说的都是我的观点，但我碰巧认为它是基于良好的常识......以及大量阅读。请记住，尽可能多疑，让事情尽可能难以侵入，然后，如果您仍然担心，请联系白帽黑客或密码学家，看看他们对您的代码/系统有何看法。