“把密码做一次 SHA-256 再存数据库”听起来比明文安全，但仍然不是合格的密码存储方案。选择算法前，必须先区分文件完整性、带密钥的消息认证和密码验证这三种需求。
文件摘要：使用 SHA-256 或 SHA-512
摘要用于判断内容是否变化。例如发布方提供一个安装包及其 SHA-256，下载者可以重新计算并比较结果。Hash 计算器支持 MD5、SHA-1、SHA-256、SHA-384 和 SHA-512，计算过程在浏览器本地完成。
MD5 和 SHA-1 已经不适合抵抗恶意碰撞。它们可以用于兼容旧系统或核对非安全场景中的既有摘要，但新系统应优先使用 SHA-256 或更强算法。
摘要只能证明“输入相同”，不能证明摘要是谁生成的。攻击者如果能同时替换文件和公开摘要，普通 Hash 无法发现问题。
消息认证：使用 HMAC
HMAC 把共享密钥和哈希算法组合起来，可用于验证消息完整性和来源。常见场景包括 Webhook 签名和服务间请求签名。HMAC 计算器支持 SHA-1、SHA-256、SHA-384 和 SHA-512。
真实系统还需要明确字节编码、签名原文拼接方式、输出格式以及常量时间比较。不要把生产密钥粘贴到不受控环境中；示例调试应使用临时密钥。
密码存储：使用专门的慢速算法
通用 SHA 算法计算速度很快，这对文件摘要是优点，对密码存储却是缺点。攻击者可以高速尝试大量候选密码。生产系统应使用专门的密码哈希算法：
- 优先考虑 Argon2id，并根据服务器资源配置内存、迭代次数和并行度。
- 无法使用 Argon2id 时，可以选择 scrypt。
- 需要兼容成熟框架时，可以使用配置合理成本参数的 bcrypt。
这些操作应该由后端成熟库完成，并为每个密码生成独立随机盐。DevToolbox 当前的 Hash 计算器不提供 Argon2、scrypt 或 bcrypt，因此不应拿它生成数据库中的密码字段。
密码检查器实际检查什么？
密码检查器在浏览器本地执行一组启发式规则，包括长度、大小写字母、数字、特殊字符、常见弱密码片段、重复字符，以及是否包含输入的用户名或邮箱片段。
它不会查询泄露密码数据库，也不能估算特定攻击者的真实破解成本。通过全部规则只表示没有触发当前检查项，不代表密码绝对安全。更稳妥的做法是使用密码管理器生成唯一长密码，并在服务支持时开启多因素认证。
实际选择表
| 需求 | 推荐方案 | 不应使用 |
|---|---|---|
| 文件或文本摘要 | SHA-256 / SHA-512 | MD5 用于安全校验 |
| 带密钥的请求签名 | HMAC-SHA-256 等 | 直接拼接密钥后做 Hash |
| 数据库密码存储 | Argon2id / scrypt / bcrypt | MD5、SHA-1、单次 SHA-256 |
| 生成个人密码 | 密码管理器或密码生成器 | 多站点重复使用同一密码 |
算法名称不是安全性的全部。参数配置、密钥管理、限速、多因素认证和升级策略同样重要。