PHP如何安全地存储用户密码_PHP用户密码哈希加密存储方案

答案是使用PHP的password_hash()和password_verify()函数配合PASSWORD_DEFAULT算法。该方法自动处理盐值、采用Bcrypt哈希算法，具备抗暴力破解、防彩虹表攻击和自适应升级等特性，是当前安全存储用户密码的最佳实践。

PHP安全存储用户密码的核心在于，我们绝不能直接存储明文密码，也不要依赖那些看似加密实则脆弱的算法，比如MD5或SHA1。最稳妥且现代的做法是使用专门的密码哈希函数，它能将密码转换为一串不可逆的字符串，并且每次哈希结果都不同，大大增加了破解难度。PHP内置的

password_hash()

解决方案

要安全地存储用户密码，我们应该始终使用PHP提供的

password_hash()

password_verify()

当你接收到用户提交的明文密码时，第一步就是用

password_hash()

PASSWORD_DEFAULT

立即学习“PHP免费学习笔记（深入）”；

当用户尝试登录时，你需要将他们输入的密码与数据库中存储的哈希值进行比对。这里我们不是直接比较哈希值，而是使用

password_verify()

password_verify()

PHP中，究竟该用哪种哈希算法来加密用户密码，才算真正安全？

在我看来，在PHP的世界里，如果你还在纠结用MD5、SHA1，甚至SHA256、SHA512这样的传统哈希算法来“加密”用户密码，那基本就是给自己挖坑。这些算法设计初衷是用于数据完整性校验，而不是密码存储。它们速度太快，这意味着攻击者可以以极高的效率进行暴力破解或彩虹表攻击。

那么，真正安全的选择是什么？答案非常明确：

password_hash()

PASSWORD_DEFAULT

PASSWORD_BCRYPT

为什么是Bcrypt？

1. 慢，才是王道： Bcrypt被设计成计算密集型的。它有意地减慢哈希过程，这对于单个用户登录来说是微不足道的延迟，但对于攻击者尝试数百万甚至数十亿次猜测时，这种“慢”就成了巨大的障碍。它使得暴力破解变得成本极高，不划算。
2. 内置盐值： 每次调用

   password_hash()

   ，它都会自动生成一个随机且唯一的盐值。这个盐值会被嵌入到最终的哈希字符串中。盐值的作用是确保即使两个用户设置了相同的密码，它们的哈希值也完全不同，从而有效防御彩虹表攻击。
3. 自适应性： Bcrypt允许你调整其“成本因子”（cost factor），这决定了哈希操作的计算强度。随着硬件性能的提升，你可以增加成本因子，让哈希过程变得更慢，从而保持与时俱进的安全性。

   PASSWORD_DEFAULT

   的优势在于，PHP会根据当前环境自动选择一个合理的成本因子，并且未来PHP版本升级时，它还会自动选择更强的算法，省去了我们手动维护的麻烦。
4. 不可逆： 这是一个哈希算法的基本要求。从哈希值无法直接推导出原始密码，这是我们安全存储的基石。

所以，我的建议是：无脑使用

PASSWORD_DEFAULT

PASSWORD_BCRYPT

PASSWORD_DEFAULT

中国工商网电子商务购物中心系统EMall

完全公开源代码，并无任何许可限制 特别基于大型电子商务网站的系统开发 Microsoft SQL Server 2000后台数据库，充分应用了存储过程的巨大功效 基于类模块的扩展数据访问能力支持任何类型的大型数据库 加密用户登录信息(cookie) 易于安装的系统和应用功能 100%的asp.net的代码，没有COM，java或者其他的格式 完全基于MS建议的系统安全设计 最佳的应用程序,数据库

下载

除了密码哈希，我们还能做些什么来筑牢用户数据防线？

仅仅哈希密码，虽然是基础且关键的一步，但它绝不是用户安全防护的终点。现实世界的攻击手段层出不穷，我们必须构建一个多层次的防御体系。

1. 强制使用强密码策略： 尽管密码哈希很强大，但如果用户密码是“123456”或“password”，那哈希也救不了它。我们应该在注册或修改密码时，强制用户使用包含大小写字母、数字和特殊字符，且长度至少在8-12位以上的密码。这可以通过前端JS校验和后端PHP校验双重实现。
2. 限制登录尝试次数（Rate Limiting）： 防止暴力破解最直接的手段之一。如果一个IP地址或一个用户名在短时间内多次尝试登录失败，就应该暂时锁定该账户或IP一段时间。这可以防止攻击者无限次地猜测密码。我通常会结合Redis或者数据库来记录尝试次数和时间戳。
3. 两步验证（Two-Factor Authentication, 2FA）： 这是提升账户安全性的“杀手锏”。即使攻击者拿到了用户的密码哈希并设法破解了它，没有第二因子（比如手机验证码、Authenticator App）也无法登录。这大大提高了攻击门槛。实现2FA可以考虑使用TOTP（基于时间的一次性密码）算法，有很多成熟的库可以集成。
4. 安全会话管理： 用户登录后，会话（Session）的安全同样重要。
   • 使用HTTPS： 确保所有通信都通过加密连接进行，防止中间人攻击窃取会话ID。
   • 定期更新会话ID： 用户登录成功后，应该立即生成新的会话ID，防止会话固定攻击。
   • 设置合理的会话过期时间： 闲置过久的会话应该自动失效。
   • HttpOnly和Secure标志： 设置Cookie时，确保

     HttpOnly

     标志开启，防止XSS攻击通过JavaScript窃取会话Cookie；

     Secure

     标志则确保Cookie只在HTTPS连接下发送。
5. 防范SQL注入和XSS： 这些是Web应用最常见的漏洞，如果数据库被注入，攻击者可以直接读取或修改用户数据，包括密码哈希。使用预处理语句（Prepared Statements）是防范SQL注入的黄金法则。对于XSS，任何用户输入在显示到页面上之前都必须进行适当的转义。
6. 日志记录与监控： 记录所有重要的安全事件，比如登录失败、密码修改尝试、账户锁定等。并定期审查这些日志，以便及时发现异常行为。

这些措施并非相互独立，而是共同构筑起一道坚固的防线。在我做过的项目中，通常会优先实现强密码策略、哈希存储和HTTPS，然后逐步引入2FA和更精细的日志监控。

用户忘记密码了，一套安全且用户友好的重置流程该怎么设计？

用户忘记密码是一个再常见不过的场景，设计一个既安全又方便的密码重置流程，是用户体验和安全之间的一个微妙平衡。我个人觉得，核心在于“一次性使用”和“时效性”。

以下是我通常会采用的设计思路：

1. 用户发起重置请求：

   • 用户在登录页面点击“忘记密码”。
   • 系统要求用户输入注册时使用的邮箱或用户名。
   • 重要： 无论用户输入的邮箱是否存在，系统都应该返回一个模糊的成功提示（例如：“如果您的账户存在，我们已发送重置链接到您的邮箱。”）。这样做是为了防止通过重置功能来枚举用户账户。

2. 生成并发送重置链接：

   • 如果邮箱/用户存在，系统生成一个唯一、随机且具有时效性的重置令牌（Token）。这个令牌应该足够长，难以猜测，并且最好包含一些特殊字符。
   • 将这个令牌与用户的ID、生成时间戳以及一个“已使用”标志（初始为

     false

     ）存储在数据库的

     password_resets

     或类似表中。
   • 将包含此令牌的重置链接发送到用户的注册邮箱。例如：

     https://yourdomain.com/reset-password?token=YOUR_UNIQUE_TOKEN

   • 再次强调： 邮件内容应明确告知用户，如果不是本人操作，请忽略此邮件，并建议用户不要将链接分享给他人。

3. 用户点击重置链接：

   • 用户点击邮件中的链接，系统接收到请求，并从URL中获取令牌。
   • 系统查询数据库，根据令牌查找对应的记录。
   • 安全检查：
     • 令牌是否存在且未被使用？ 如果不存在或已被使用，提示链接无效或已过期。
     • 令牌是否在有效期内？ 我通常会设置一个较短的有效期，比如15分钟到1小时。如果过期，提示链接已过期，需要重新发起请求。
     • 双重验证： 某些高安全要求场景下，可能会要求用户在点击链接后，再次输入部分个人信息（如用户名或注册时手机号后四位）进行二次验证。

4. 设置新密码：

   • 如果所有安全检查通过，系统显示一个表单，让用户输入并确认新密码。
   • 密码策略： 在这里，必须强制用户设置一个强密码，与注册时的要求一致。
   • 用户提交新密码后，系统使用

     password_hash()

     函数对新密码进行哈希处理，并更新数据库中该用户的密码。
   • 重要： 密码更新成功后，立即将数据库中对应的重置令牌标记为“已使用”或直接删除，确保该令牌不能再次被利用。

5. 完成与通知：

   • 密码重置成功后，引导用户回到登录页面，并建议他们使用新密码登录。
   • 同时，最好再发送一封通知邮件给用户，告知其密码已成功重置。这既能让用户安心，也能在非本人操作时提供预警。

整个流程中，核心是确保重置令牌的唯一性、随机性和时效性，并且严格控制其使用次数。避免将任何敏感的用户信息直接包含在重置链接中，始终通过安全的服务器端查找来验证令牌。