目前认为MD5是部分不安全的。考虑到这一点，我想知道使用哪种机制来保护密码。
这个问题，“双重哈希”密码是否比只哈希一次更不安全? 建议哈希多次可能是一个好主意，而如何实现个别文件的密码保护?建议使用盐。
我用的是PHP。我想要一个安全快捷的密码加密系统。对一个密码进行一百万次哈希运算可能更安全，但也更慢。如何在速度和安全之间取得良好的平衡?此外，我更希望结果具有恒定数量的字符。
哈希机制必须在PHP中可用 必须是安全的 它可以使用盐(在这种情况下，所有的盐都一样好吗?有没有办法生产出好的盐?)
另外，我是否应该在数据库中存储两个字段(例如，一个使用MD5，另一个使用SHA)?这会让它更安全还是更不安全?
以防我不够清楚，我想知道要使用哪个哈希函数，以及如何选择一个好的盐，以便拥有一个安全和快速的密码保护机制。
没有完全涵盖我的问题的相关问题:
PHP中的SHA和MD5有什么区别 简单密码加密 为asp.net存储密钥和密码的安全方法 如何在Tomcat 5.5中实现加盐密码
当前回答
一个更简短、更安全的答案是:完全不要编写自己的密码机制，使用经过验证和测试的机制。
PHP 5.5或更高版本:password_hash()质量很好，是PHP核心的一部分。 PHP 4。x(过时):OpenWall的phpass库比大多数自定义代码(用于WordPress、Drupal等)要好得多。
大多数程序员只是不具备在不引入漏洞的情况下安全地编写加密相关代码的专业知识。
快速自测:什么是密码拉伸，应该使用多少次迭代?如果你不知道答案，你应该使用password_hash()，因为密码扩展现在是密码机制的一个关键特性，这是由于更快的cpu和gpu和fpga的使用，以每秒数十亿次的猜测速度破解密码(gpu)。
截至2012年，你可以在5台台式电脑上安装25个图形处理器，在6小时内破解所有8个字符的Windows密码。这是强制的，即枚举和检查每个8个字符的Windows密码，包括特殊字符，而不是字典攻击。有了现代gpu，你当然可以破解更多的密码，或者使用更少的gpu——或者以合理的价格在云中租用gpu几个小时。
还有很多针对Windows密码的彩虹表攻击，它们运行在普通cpu上，速度非常快。
这一切都是因为，即使在Windows 10中，Windows也没有对密码进行腌制或拉伸。2021年依然如此。不要犯和微软一样的错误!
参见:
很好的回答，更多关于为什么password_hash()或phpass是最好的方法。 一篇很好的博客文章，给出了主要算法的推荐“工作因子”(迭代次数)，包括bcrypt, scrypt和PBKDF2。
其他回答
需要记住的事情
关于PHP密码加密已经说了很多，其中大多数都是非常好的建议，但是在开始使用PHP进行密码加密之前，请确保您已经实现了以下内容或准备实现以下内容。
服务器
港口
无论您的加密技术有多好，如果您不能正确地保护运行PHP和DB的服务器，那么您所有的努力都是徒劳的。大多数服务器的功能相对相同，它们都有指定的端口，允许您通过ftp或shell远程访问它们。确保您更改了活动的任何远程连接的默认端口。如果不这样做，实际上就使攻击者在访问您的系统时少做了一步。
用户名
在这个世界上，最好不要使用admin、root或类似的用户名。此外，如果你是在一个基于unix的系统上，不要让根帐户登录可访问，它应该总是只有sudo。
密码
你告诉你的用户要设置好的密码以避免被黑客攻击，你也要这么做。当后门大开着的时候，费劲地锁上前门又有什么意义呢?
数据库
服务器
理想情况下，您希望DB和APPLICATION位于不同的服务器上。由于成本原因，这并不总是可行的，但它确实具有一定的安全性，因为攻击者必须通过两个步骤才能完全访问系统。
USER
始终让您的应用程序拥有自己的帐户来访问DB，并且只给它所需的特权。
然后为您创建一个单独的用户帐户，该帐户不存储在服务器上的任何地方，甚至不存储在应用程序中。
比如总是不要做这个根或类似的东西。
密码
遵循与所有好密码相同的原则。另外，不要在同一系统上的任何SERVER或DB帐户上重复使用相同的密码。
PHP
密码
永远不要在你的数据库中存储密码，而是存储哈希和唯一的盐，我将在后面解释为什么。
哈希
单向哈希!!!!!!!永远不要以一种可以反转的方式哈希密码，哈希值应该是一种方式，这意味着你不反转它们并将它们与密码进行比较，而是以同样的方式哈希输入的密码并比较两个哈希值。这意味着即使攻击者访问了数据库，他也不知道实际的密码是什么，只知道其结果哈希值。这意味着在最糟糕的情况下为用户提供更多的安全性。
有很多不错的散列函数(password_hash, hash等等)，但是为了使散列有效，您需要选择一个好的算法。(bcrypt和类似的算法都是不错的算法。)
当哈希速度是关键时，越慢越能抵抗暴力攻击。
哈希中最常见的错误之一是哈希值对用户来说不是唯一的。这主要是因为盐不是唯一产生的。
盐
在散列之前，密码应该始终加盐。Salting在密码中添加一个随机字符串，这样类似的密码在DB中就不会出现相同的密码。然而，如果盐对每个用户都不是唯一的(例如:你使用了硬编码的盐)，那么你几乎已经让你的盐变得毫无价值。因为一旦攻击者找到了一个密码盐，他就有了所有密码盐。
当你创建一个salt时，确保它是唯一的密码，然后将完成的散列和salt存储在你的DB中。这将使攻击者在获得访问权限之前必须单独破解每个盐和哈希。这对攻击者来说意味着更多的工作和时间。
用户创建密码
如果用户通过前端创建密码，则意味着必须将密码发送到服务器。这就产生了一个安全问题，因为这意味着未加密的密码将被发送到服务器，如果攻击者能够监听和访问，那么PHP中的所有安全性都是毫无价值的。始终安全地传输数据，这是通过SSL完成的，但即使SSL也不是完美无缺的(OpenSSL的Heartbleed缺陷就是一个例子)。
还要让用户创建一个安全的密码，这很简单，应该一直这样做，用户最终会感激它。
最后，无论你采取什么安全措施，没有什么是100%安全的，保护的技术越先进，攻击就会变得越先进。但是，遵循这些步骤将使您的站点更加安全，并且攻击者更不愿意进行攻击。
下面是一个PHP类，它可以轻松地为密码创建散列和盐
http://git.io/mSJqpw
我通常使用SHA1和salt和用户ID(或其他特定于用户的信息)，有时我还使用常数salt(因此我有2部分salt)。
SHA1 is now also considered somewhat compromised, but to a far lesser degree than MD5. By using a salt (any salt), you're preventing the use of a generic rainbow table to attack your hashes (some people have even had success using Google as a sort of rainbow table by searching for the hash). An attacker could conceivably generate a rainbow table using your salt, so that's why you should include a user-specific salt. That way, they will have to generate a rainbow table for each and every record in your system, not just one for your entire system! With that type of salting, even MD5 is decently secure.
我不会以两种不同的方式存储哈希密码，因为这样的话，系统至少和正在使用的最弱的哈希算法一样弱。
最后，在数学上，双重哈希没有任何好处。然而，在实践中，它对于防止基于彩虹表的攻击是有用的。换句话说，它并不比使用salt进行哈希更有好处，后者在应用程序或服务器上占用的处理器时间要少得多。
谷歌表示SHA256对PHP可用。
你一定要加盐。我建议使用随机字节(不要限制自己使用字符和数字)。通常情况下，你选择的时间越长，就越安全、越慢。64字节应该就可以了。
