PHP密码安全存储：password\_hash使用教程

本文深入解析了PHP中安全存储密码的正确实践，强调必须摒弃早已过时且极度危险的md5、sha1等通用哈希方式及手动加盐操作，转而全面采用内置的`password_hash()`和`password_verify()`函数——它们自动处理加盐、适配最优算法（默认PASSWORD_DEFAULT，当前为bcrypt、未来可平滑升级至Argon2），并生成长度可变但完全自包含的哈希字符串；文章还细致提醒了数据库字段需设为VARCHAR(255)、避免截断，验证时警惕空格与字符串完整性、杜绝二次哈希等关键陷阱，直击开发者在迁移旧系统、修复历史技术债时最常踩坑的真实痛点。

直接用 password_hash() 生成哈希值，存进数据库即可；别碰 md5()、sha1() 或手动拼 salt —— 这些不是“不够好”，而是已经失效。

为什么不能用 md5() 或 sha1() 存密码

它们是通用哈希函数，不是为密码设计的：计算太快、不加盐、抗碰撞能力差。现在一张消费级显卡每秒能跑上亿次 md5() 碰撞，彩虹表库也早把常见组合全预计算好了。哪怕你加了 salt，只要算法本身可高速穷举，就等于没设防。

常见错误现象：

• 数据库里看到一堆 5f4dcc3b5aa765d61d8327deb882cf99 这类固定长度 32 位字符串 —— 基本就是裸 md5()
• 登录逻辑里出现 md5($_POST['pass'] . $row['salt']) === $row['password'] —— 手动 salt 管理极易出错，且无法随硬件升级自动增强强度

password_hash() 的参数怎么选

默认调用 PASSWORD_DEFAULT 就够用，它当前指向 bcrypt，未来 PHP 升级可能切到 Argon2，但老哈希仍能被新版本验证。除非你明确知道环境限制（比如某些旧容器没装 libargon2），否则别硬写死 PASSWORD_BCRYPT 或 PASSWORD_ARGON2ID。

可选的 $options 数组里，最常调的是 cost：

• cost => 10 到 12 是合理区间；值每 +1，计算耗时约翻倍
• 设太高（如 16）会导致登录延迟明显，尤其高并发时可能拖垮 Web 服务
• 设太低（如 8）会让暴力破解成本大幅下降，失去 bcrypt 意义
• 不需要传 salt 参数 —— 函数内部自动生成并嵌入输出字符串，手动传反而会触发弃用警告

数据库字段要怎么设计

password_hash() 输出的字符串长度不固定，但当前 bcrypt 最长约 60 字符，Argon2 可达 255 字符。若字段类型是 VARCHAR(32) 或 CHAR(32)，插入会截断，导致后续 password_verify() 必然失败。

实操建议：

• MySQL 中设为 VARCHAR(255)，足够容纳所有当前及可预见的未来算法输出
• 别用 TEXT —— 虽然能存，但索引效率低，且无必要
• 字段名就叫 password_hash，别叫 password 或 pwd，避免语义混淆
• 插入前不用额外过滤或转义 —— 哈希字符串只含 ASCII 可打印字符，不会触发 SQL 注入

password_verify() 验证时容易忽略的点

它不依赖外部 salt 或算法配置，只靠哈希字符串自身携带的元信息工作。但有几点必须注意：

• 第二个参数必须是完整原始哈希字符串（例如 $2y$10$...），不能是截断的、trim() 过的、或从 JSON 中 decode 出来时被意外转义的
• 如果数据库字段被定义为 CHAR 且长度大于实际内容，MySQL 可能自动补空格 —— password_verify() 会因末尾空格校验失败，查出来后记得 rtrim()
• 不要在验证前对用户输入做任何哈希（比如先 md5() 再传给 password_verify()）—— 它只接受明文密码
• 验证失败时，统一返回“用户名或密码错误”，别暴露“密码错”还是“用户不存在”，防止用户名枚举

真正麻烦的从来不是函数怎么调，而是旧系统里那些 md5($pass.$salt) 的遗留逻辑、字段长度卡死的表结构、以及开发时顺手写的 echo $hash 调试语句 —— 它们比算法本身更难清理干净。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~