摘要
密码验证是很常见的需求，如何在实现功能之余，防止用户密码泄露，已经有了很成熟的方案。这篇文章把自己的思考和结论做一下记录。
对用户密码进行加密时需要做到：
防止用户密码明文被窃听
1.交给https，明文传输。
2.客户端将密码加盐（盐随机生成、具有强度）并哈希。服务端再次加盐哈希并对比。假设https被窃听，攻击者破解密码明文也具有相当难度。
防止数据库被攻破时，用户密码明文被窃取。
1.增加哈希算法强度。
2.随机生成具有强度的盐。
一些思考
哈希算法是不可逆的。攻击者可以生成海量的密码 -> 哈希值键值对，反向映射，有概率通过哈希值得到密码。
故，破解的成本=哈希算法强度×盐值数量。
如何选择哈希算法强度
- 计算耗时用户可接受（视应用场景，如0.2s内）。
- 计算耗时尽量长，即增加哈希算法强度。
为什么盐要随机
如果盐不随机，攻击者可以针对单个盐生成哈希值->密码键值对，再对整个数据库的哈希值做匹配。
假设盐是保密的，盐可能因为各种原因被攻击者获取（代码泄漏、社会工程学等等）。
攻击者也可以通过在数据库被攻破的网站上注册用户，通过 哈希值->攻击者密码 盐 来破解盐。
为什么盐要有强度
如果盐的强度（长度）不够。攻击者可以建立多个 哈希值->密码 数据库，简单盐被匹配（攻破）的概率更高。
为什么盐可以明文存储
攻击者很难有足够的计算资源和存储空间建立海量的 哈希值->密码 数据库，针对单条用户记录，建立 哈希值->密码 数据库进行攻击的成本过高。
php的实现
最初的想法
需求是房间密码，出于简单考虑，我最初的想法是，md5 随机盐。
在数据库里大致是这样：
------- ------------- ------ ----- --------- ------- | field | type | null | key | default | extra | ------- ------------- ------ ----- --------- ------- | uid | int(11) | no | pri | null | | | pwd | varchar(45) | yes | | null | | | salt | varchar(45) | yes | | null | | ------- ------------- ------ ----- --------- -------
php的推荐实现
php的md5文档
给了一个很好的指引：
password_hash 和 crypt 函数返回值的组成部分，依次为：所选择的算法，算法选项，所使用的“盐”，以及散列后的密码。
更改后、数据库表变为：
------- ------------- ------ ----- --------- ------- | field | type | null | key | default | extra | ------- ------------- ------ ----- --------- ------- | uid | int(11) | no | pri | null | | | pwd | varchar(255) | yes | | null | | ------- ------------- ------ ----- --------- -------
相较之前的方案：
1.记录了采用的算法（可以在不改动代码的情况下升级算法）
2.记录了采用算法的cost（强度），可以在硬件计算能力上升的情况下，调整cost来维持安全性。
3.盐和哈希值一并返回，简化了接口调用、数据库存储。
php的验证接口设计得相当漂亮。
使用简单，强制调用者使用随机的salt（不容易误用），可在不修改代码的情况下拓展算法强度。
代码：
if (!empty($xxxx_info['pwd'])) { // 若原来有密码，则要检测
if (!password_verify($old_pwd, $xxxx_info['pwd'])) {
// 用户名或密码错
return;
}
}
// 对密码长度、内容等不做限制。
// 以应用场景来说，123456之类也无所谓。
$pwd_in_db = password_hash($new_pwd, password_default, array("cost" => 6));
参考
以上就是php对用户密码进行加密技巧实例的详细内容，更多关于php用户密码加密的资料请关注其它相关文章！
