哈希类型识别
按长度、字符集和前缀判断一段摘要用了什么算法，支持主流哈希与口令派生格式。
哈希值识别
按长度、字符集和前缀判断，结果按可能性从高到低排列。
判断依据
哈希算法本身不可逆，但从摘要的长度和字符集可以大幅缩小范围。识别结果只是候选，真正的确认要靠已知明文比对或查看系统配置，不能仅凭长度下结论。
几类容易混淆的情况
32 位十六进制既可能是 MD5，也可能是 NTLM 或部分系统的自定义截断；40 位是 SHA1 的典型长度，但 MySQL 的 PASSWORD() 老函数也输出 40 位；64 位对应 SHA256，也对应 Keccak-256 和部分 Blake2 变体。带 $ 前缀的格式辨识度最高，$2a$、$2b$、$2y$ 是 bcrypt，$argon2id$ 是 Argon2，$6$ 是 SHA512-crypt。
为什么这件事有用
做代码审计或渗透测试时，从数据库或配置里翻出一串哈希，第一步就是判断它用的是什么算法。如果确认是 MD5 或 SHA1 这类快速哈希，说明口令存储方案需要改造；如果是 bcrypt 或 Argon2 且 cost 参数合理，则风险相对可控。密评和等保测评里，口令存储方式是必查项。
常见哈希格式速查
| 长度 / 前缀 | 可能算法 | 典型用途 |
|---|---|---|
| 16 位十六进制 | MySQL PASSWORD 早期、部分自定义截断 | 遗留系统 |
| 32 位十六进制 | MD5、NTLM | 文件校验、Windows 口令 |
| 40 位十六进制 | SHA1、MySQL PASSWORD() | 旧版校验、代码仓库指纹 |
| 56 位十六进制 | SHA224 | 较少见 |
| 64 位十六进制 | SHA256、Keccak-256、Blake2s | 数据完整性、区块链 |
| 96 位十六进制 | SHA384 | 较少见 |
| 128 位十六进制 | SHA512、Whirlpool | 高强度校验 |
| 60 位，$2a$/$2b$/$2y$ | bcrypt | 口令存储 |
| $argon2i$/$argon2id$ | Argon2 | 口令存储 |
| $1$ / $5$ / $6$ | MD5-crypt / SHA256-crypt / SHA512-crypt | Linux 口令文件 |
| $pbkdf2-sha256$ | PBKDF2 | 口令派生、密钥派生 |
常见问题
识别结果能直接确定算法吗？▼
不能。长度和字符集只能排除大部分可能，同一长度可能对应多种算法。要确认需要结合来源系统判断，比如从数据库口令字段取出来的 60 位 $2b$ 前缀基本可以确定是 bcrypt，而 32 位十六进制在文件和口令场景下含义不同。
为什么 32 位的哈希有可能是 NTLM？▼
NTLM 是 Windows 的挑战响应协议，其存储形式是 MD4 摘要，长度同样是 32 位十六进制。单看长度无法与 MD5 区分，需要看来源是 Windows 系统还是 Web 应用。
MD5 和 SHA1 还能用吗？▼
用于文件完整性校验这类非安全场景问题不大，用于口令存储和数字签名则不合适。这两类算法已被证明存在碰撞攻击，等保测评和密评都会把口令存储算法列为检查项，建议改用 bcrypt、Argon2 或 PBKDF2。
bcrypt 的 cost 参数多少合适？▼
常见取值 10 到 12。cost 每加一，计算耗时翻倍。12 在主流服务器上单次约 200 到 300 毫秒，兼顾安全与登录体验。具体要按服务器性能和登录并发量压测后确定。
国密场景用什么哈希？▼
SM3 是我国商用密码杂凑算法标准，输出 256 位，长度与 SHA256 相同，无法仅凭长度区分。涉及密评的信息系统应按要求使用 SM3，本工具页的相关链接里有 SM3 计算工具。