目前有人称MD5算法存在部分不安全的问题。考虑到这一点，我想知道哪种机制适合用于密码保护。
一个名为《双重哈希是否比单次哈希更不安全？》的问题建议多次哈希可能是个好主意，而《如何为单个文件实现密码保护？》则建议使用盐。
我使用PHP。我想要一个既安全又快速的密码加密系统。虽然密码哈希百万次可能更安全，但也更慢。如何在速度和安全之间取得平衡？此外，我希望结果具有恒定数量的字符。
此外，我应该在数据库中存储两个字段（例如一个使用MD5，另一个使用SHA）吗？这会使它更安全还是更不安全？
如果我的表述不够清晰，我想知道哪些哈希函数和如何选择好的盐以获得一个既安全又快速的密码保护机制。
以下是一些相关问题，但并未完全涵盖我的问题：
SHA和MD5在PHP中有什么区别
简单密码加密
ASP.NET安全存储密钥、密码的方法
如何在Tomcat 5.5中实现加盐密码
password_hash和password_verify，自从它们被引入以来，它们是推荐的密码哈希和检查方法。\0的输入，这可能会严重削弱安全性。）哈希密码背后的目标很简单：通过破坏数据库来防止恶意访问用户帐户。因此，密码哈希的目标是通过花费太多时间或金钱来计算明文密码来阻止黑客或破解者。时间/成本是您武器库中最好的威慑因素。
另一个你想要在用户帐户上有一个好的、强大的哈希的原因是给你足够的时间来改变系统中的所有密码。如果您的数据库被攻击，您需要足够的时间来至少锁定系统，如果可能，更换数据库中的每个密码。
Jeremiah Grossman，Whitehat Security的CTO，在最近一次需要强制破解他的密码保护的密码恢复之后在White Hat Security博客上说：
有趣的是，在经历这个噩梦时，我学到了很多关于密码破解、存储和复杂性的知识。我开始认识到为什么密码存储比密码复杂性更重要。如果你不知道你的密码是如何存储的，那么你所依赖的只是复杂性。对于密码和加密专家来说，这可能是常识，但对于普通信息安全或网络安全专家来说，我非常怀疑。在Crypto StackExchange网站上有关于密码熵的更长讨论。良好的Google搜索也会得到很多结果。
在评论中，我与@popnoodles交谈，他指出强制使用X个字母、数字、符号等长度为X的密码策略实际上会通过使密码方案更加可预测来降低熵。我同意。随机性越真实的解决方案总是最安全但记忆最差的解决方案。
就我所知，创造世界上最好的密码是一个进退两难的局面。它要么不容易记忆，太容易预测，太短，太多Unicode字符（在Windows/Mobile设备上难以输入），太长等等。没有任何一个密码对我们的目的来说是完全足够的，因此我们必须像保护金库一样保护它们。
Bcrypt和scrypt是目前的最佳实践。 Scrypt将来会比bcrypt更好，但它还没有被Linux / Unix或Web服务器采用为标准，并且还没有对其算法进行深入审查。但未来的算法看起来很有前途。如果您正在使用Ruby，则有一个scrypt gem可以帮助您，Node.js现在有自己的scrypt包。您可以通过Scrypt扩展或Libsodium扩展（两者都可在PECL中获得）在PHP中使用Scrypt。
我建议阅读crypt函数的文档以了解如何使用bcrypt，或者找到一个好的 包装器或使用类似于PHPASS的更传统的实现。如果不是15至18轮，则建议至少使用12轮bcrypt。PHP 5.5中即将推出一个全面的密码保护库，它抽象了使用bcrypt时的任何痛苦。虽然我们大多数人在常见环境中仍然使用PHP 5.2和5.3，特别是共享主机，但@ircmaxell已经为即将推出的API构建了一个兼容层，向后兼容到PHP 5.3.7。
password_hash()，因为由于更快的 CPU 和GPU 和 FPGA用于以每秒数十亿次猜测（使用 GPU）的速度破解密码，密码拉伸现在是密码机制的一个关键特性。
hashcat，NTLM密码的每秒2880亿个哈希值）。这一切都是因为Windows仍然没有对其密码进行加盐或拉伸，即使在Windows 10或11中也是如此，因为它需要允许NTLMv1登录。
这在2023年仍然是事实 - 请参阅此问答。
不要犯和微软一样的错误！
password_hash()或phpass是最佳选择的内容。对于非常旧的PHP（4.x）：OpenWall的phpass库比大多数自定义代码更好 - 在WordPress、Drupal等中使用。
我不会以两种不同的方式存储哈希密码，因为这样系统的弱点至少和使用的哈希算法中最弱的一种一样。
从PHP 5.5开始，PHP具有用于哈希和验证密码的简单且安全的函数：password_hash()和password_verify()
$password = 'anna';
$hash = password_hash($password, PASSWORD_DEFAULT);
$expensiveHash = password_hash($password, PASSWORD_DEFAULT, array('cost' => 20));
password_verify('anna', $hash); //Returns true
password_verify('anna', $expensiveHash); //Also returns true
password_verify('elsa', $hash); //Returns false
password_hash()函数时，它会生成一个随机盐并将其与算法和密码成本一起包含在输出的哈希中。然后，password_verify()函数读取该哈希值并确定所使用的盐和加密方法，并将其与提供的纯文本密码进行验证。PASSWORD_DEFAULT指令告诉PHP使用已安装的PHP版本的默认哈希算法。未来的版本中，这意味着确切使用哪个算法可能会发生变化，以便始终使用其中一个最强大的可用算法。password_verify()会检测到它。虽然这个问题已经得到了回答，但我想再强调一下，用于哈希的盐应该是随机的，而不像第一个答案中建议的那样使用电子邮件地址。
更多解释请参见（archive.org的备份）http://www.pivotalsecurity.com/blog/password-hashing-salt-should-it-be-random/
最近我进行了一次讨论，讨论的问题是用随机位盐串联密码哈希是否比使用可猜测或已知盐更加安全。以下是我的看法：
如果存储密码的系统以及存储随机盐的系统都被攻击者入侵，攻击者将能够访问哈希和盐，因此无论盐是否随机并不重要。攻击者可以生成预计算的彩虹表来破解哈希。现在有趣的部分来了-生成预计算表不是一件轻松的事情。我们以WPA安全模型为例。你的WPA密码实际上从未发送到无线接入点。相反，它会与你的SSID（网络名称-例如Linksys、Dlink等）一起哈希。这里有一个非常好的解释。要从哈希中检索密码，您需要知道密码以及盐（网络名称）。Church of Wifi已经预先计算了具有前1000个SSID和约1百万个密码的哈希表。所有表的大小约为40 GB。正如您可以在他们的网站上读到的那样，有人用15个FGPA数组花了3天时间来生成这些表。
假设受害者使用SSID“a387csf3”和密码“123456”，这些表能否破解它？不行！..不能。即使密码很弱，也没有SSID a387csf3的哈希。这就是使用随机盐的优点所在。它会阻止那些依赖于预计算表的黑客入侵。是否能够阻止决心很强的黑客？可能不行。但使用随机盐确实提供了额外的防御层。
谈到这个话题，让我们探讨将随机盐值存储在独立系统上的额外优势。
场景1：密码哈希值存储在系统X上，用于哈希的盐值存储在系统Y上。这些盐值是可以猜测或已知的（例如用户名）。
场景2：密码哈希值存储在系统X上，用于哈希的盐值存储在系统Y上。这些盐值是随机的。
如果系统X被攻击者攻破，显然使用独立系统上的随机盐值（场景2）有很大优势。攻击者需要猜测附加值才能破解哈希值。如果使用32位盐值，则每个猜测的密码可能需要4,294,967,296（约42亿）次迭代。
我想指出的是，PHP 5.5包含一个密码哈希API，它提供了一个对crypt() 的包装器。该API显着简化了哈希、验证和重新哈希密码哈希的任务。作者还发布了一个兼容性包（以单个password.php文件的形式提供，只需require即可使用），供那些使用PHP 5.3.7及更高版本并希望立即使用此功能的人使用。
目前仅支持BCRYPT，但旨在轻松扩展以包括其他密码哈希技术，并且因为技术和成本存储为哈希的一部分，所以对您首选的哈希技术/成本的更改不会使当前哈希无效，框架将自动使用正确的技术/成本进行验证。如果没有明确定义自己的，则还处理生成“安全”盐。
该API公开了四个函数：
password_get_info() - 返回给定哈希的信息password_hash() - 创建密码哈希值password_needs_rehash() - 检查给定哈希值是否与给定选项匹配。有助于检查哈希值是否符合您当前的技术/成本方案，以便在必要时重新哈希password_verify() - 验证密码是否与哈希值匹配目前这些函数接受PASSWORD_BCRYPT和PASSWORD_DEFAULT密码常量，它们目前是同义词，不同之处在于PASSWORD_DEFAULT“可能会在新的PHP版本中支持更强的哈希算法时更改”。在登录时使用PASSWORD_DEFAULT和password_needs_rehash()（如果需要，重新哈希）应该可以确保您的哈希在很小或没有工作的情况下相对耐用，抵御暴力攻击。
编辑：我刚意识到Robert K的答案中已经简要提到了这一点。我将保留此答案，因为我认为它提供了更多关于如何工作以及为那些不知道安全性的人提供易用性的信息。
我正在使用Phpass，这是一个简单的单文件PHP类，几乎可以在每个PHP项目中轻松实现。还请参阅The H。
默认情况下，它使用Phpass中实现的最强加密bcrypt，并回退到其他加密方式（如MD5）以提供向后兼容性，以适应像WordPress这样的框架。
返回的散列值可以按原样存储在数据库中。生成散列的示例用法如下：
$t_hasher = new PasswordHash(8, FALSE);
$hash = $t_hasher->HashPassword($password);
为了验证密码，可以使用以下方法：
$t_hasher = new PasswordHash(8, FALSE);
$check = $t_hasher->CheckPassword($password, $hash);
记住的事情
关于 PHP 的密码加密，已经有很多讲解了，其中大部分都是非常好的建议，但在你开始使用 PHP 进行密码加密之前，请确保你已经实施或准备好以下内容。
服务器
端口
无论你的加密有多好，如果你没有正确保护运行 PHP 和 DB 的服务器，那么所有的努力都是毫无意义的。大多数服务器的功能都是相对相同的，它们都有指定的端口，允许你通过 ftp 或 shell 远程访问。确保你更改默认端口，不管你正在使用哪种远程连接方式。如果你不这样做，实际上就使攻击者少进行了一步，即进入你的系统。
用户名
为了世界的和平，请不要使用 admin、root 或类似的用户名。此外，如果你使用的是基于 unix 的系统，不要让 root 账户登录可见，它应该只限于 sudo 。
密码
你要求你的用户制作好的密码以避免被黑客攻击，自己也要这样做。如果你的后门大开着，那么锁好前门还有什么意义呢？
数据库
服务器
理想情况下，你希望 DB 和 APPLICATION 在分别的服务器上。由于成本原因，这并不总是可能的，但它确实可以提供一些保护措施，因为攻击者将需要经过两个步骤才能完全访问系统。
用户
始终为你的应用程序准备一个专用的帐户来访问 DB，并仅赋予必要的权限。
然后为自己准备一个单独的用户帐户，该帐户不会存储在服务器上的任何地方，甚至不会存储在应用程序中。
像以往一样，请不要使用 root 或类似的用户名。
密码
遵循所有好密码的相同准则。此外，不要在相同系统上的任何服务器或 DB 帐户上重复使用相同的密码。
PHP
密码
永远不要将密码存储在数据库中，而是存储其哈希值和唯一盐值，稍后我会解释为什么这样做。
哈希
单向哈希！！！！！永远不要以可逆的方式对密码进行哈希，哈希应该是单向的，这意味着您不会将其反转并将其与密码进行比较，而是以相同的方式对输入的密码进行哈希并比较两个哈希值。这意味着即使攻击者可以访问数据库，他也不知道实际密码是什么，只知道其结果哈希值。这意味着在最坏的情况下为您的用户提供更多的安全保障。
有很多好的哈希函数（password_hash、hash等），但您需要选择一个好的算法才能使哈希值有效。（bcrypt和类似于它的算法都比较不错。）
当哈希速度至关重要时，速度越慢，就越抵抗暴力攻击。
哈希中最常见的错误之一是哈希值对于用户来说不是唯一的。这主要是因为盐值没有被唯一生成。
加盐
在对密码进行哈希之前，密码应始终被加盐。加盐将一个随机字符串添加到密码中，使得相似的密码在数据库中不会出现相同的情况。然而，如果盐没有为每个用户唯一生成（即：您使用硬编码盐），那么您就基本上使盐失去了价值。因为一旦攻击者找出一个密码的盐，他就有了所有密码的盐。
当您创建盐时，请确保它对于它正在加盐的密码是唯一的，然后将完成的哈希和盐存储在您的数据库中。这将使攻击者必须逐个破解每个盐和哈希才能获得访问权限。这对攻击者来说意味着更多的工作和时间。
用户创建密码
如果用户通过前端创建密码，那么就意味着密码必须发送到服务器。这会导致安全问题，因为这意味着未加密的密码正在被发送到服务器，如果攻击者能够监听和访问它，那么 PHP 中所有的安全都将毫无价值。一定要安全地传输数据，可以通过 SSL 完成，但是请注意，即使 SSL 也不是完美的（OpenSSL 的 Heartbleed 缺陷就是一个例子）。
此外，请确保用户创建一个安全密码，这很简单，也应该经常做，最终用户会感激的。
最后，无论您采取什么安全措施，没有什么是100%安全的，保护技术越先进，攻击越变得先进。但是遵循这些步骤将使您的网站更安全，攻击者的兴趣将大大降低。
这是一个 PHP 类，可以轻松创建密码的哈希和盐
谷歌表示SHA256已经可用于PHP。
您绝对应该使用盐。我建议使用随机字节（而不是仅限于字符和数字）。通常情况下，您选择的字节越长，它就越安全，但速度也会变慢。我猜64个字节应该足够了。
从数学上讲，双哈希并没有提供任何好处。然而，在实践中，它对于防止基于彩虹表的攻击非常有用。换句话说，它与使用盐值进行哈希处理的效果相同，但在应用程序或服务器上需要更少的处理器时间。