bcrypt 与 argon2 校验
bcrypt & argon2 Checker
用指定 cost 对密码做 bcrypt 哈希，并把密码和现有的 bcrypt 哈希比对；argon2 认得出来但不计算。
用 bcrypt 给密码做哈希，或者把密码和一个现有的 `$2a$`/`$2b$`/`$2y$` 哈希比对。实现是 OpenBSD 的 `$2b$`，用公开的 Openwall crypt_blowfish 测试向量验证过，在这个标签页的 worker 里运行。
只在这个标签页里处理，不往外发送。
1,024 轮 — 沿用已久的默认值。
$2b$ 那种 bcrypt，对照公开的 Openwall crypt_blowfish 测试向量验证过，全部在这个标签页里运行。密码只有前 72 字节算数——这是 bcrypt 就如此，不是这里的缺陷。 $2x$ 哈希（由 2011 年之前的 crypt_blowfish 缺陷造成）会被拒绝，argon2 也没有实现。怎么用
选哈希还是校验
哈希需要一个 cost；校验从你粘贴的哈希里读出 cost，因为它就存在那个字符串里。
选一个你负担得起的 cost
每加一级工作量翻倍。10 当了很多年的默认值，12 是当前扎实的选择，14 在浏览器里要花几秒钟能感觉到——这正是意义所在：攻击者也要花那么久。
读结论
匹配或不匹配。一切都在标签页里发生，所以粘到这里的生产环境哈希不会去往任何地方。
常见问题
为什么 argon2 是被拒绝而不是被支持？
因为浏览器里一个可信的 argon2 意味着要带上一份这个项目无法逐行审计的 WebAssembly 构建。bcrypt 在这里是用你能读的代码实现的，并用公开向量核对过。拒绝一个 argon2 哈希，比从黑盒里给出一个看起来像样的答案更诚实。
为什么我的长密码能和错的哈希匹配上？
bcrypt 只读前 72 个字节。前 72 个字节相同的两个密码对它来说是同一个密码——这是 bcrypt 本身，不是这个实现。它对长口令有影响，也是人们转向 argon2 的一个原因。
为什么同一个密码哈希两次得到不同的字符串？
因为每次运行都生成一个新的 16 字节盐，盐随哈希一起存放。两个字符串都能校验同一个密码。每次都一样的密码哈希是没有盐的密码哈希，彩虹表正是为它造的。
$2a$、$2b$ 和 $2y$ 不同吗？
对任何 72 字节以内的密码——也就是所有密码——没有区别。这些前缀记录的是一个哈希在某个历史 bug 之前还是之后生成。`$2x$` 是例外——它标记 2011 年前 crypt_blowfish 一个 bug 产生的哈希，这里会拒绝它们。
可以从这些接进来
文本哈希计算
Text Hash
算出字符串的 MD5、SHA-1、SHA-256、SHA-384、SHA-512 和 CRC-32，输出可选大写或 Base64。
哈希类型识别
Hash Identifier
按长度、字符构成和前缀推测一段哈希是哪种算法生成的，按可能性排序。
.htpasswd 生成
.htpasswd Generator
用 bcrypt、APR1 或 SHA 生成 Apache 或 nginx 的基本认证条目。
JSON 格式化与校验
JSON Formatter & Validator
把 JSON 美化成缩进形式或压成一行，校验语法并直接指出出错的行和列。
接下来
这些工具吃得下当前工具的产出，结果可以直接送过去。
哈希类型识别
Hash Identifier
按长度、字符构成和前缀推测一段哈希是哪种算法生成的，按可能性排序。
文本哈希计算
Text Hash
算出字符串的 MD5、SHA-1、SHA-256、SHA-384、SHA-512 和 CRC-32，输出可选大写或 Base64。
.htpasswd 生成
.htpasswd Generator
用 bcrypt、APR1 或 SHA 生成 Apache 或 nginx 的基本认证条目。
密码强度检测
Password Strength Meter
估算一个密码要多久才会被破解，并点名是哪些套路让它变弱的。
Base64 编码解码
Base64 Encoder & Decoder
对文本和文件做 Base64 与 Base64URL 编解码，UTF-8 处理正确。
curl 转代码
curl to Code
把一条 curl 命令转成 fetch、axios、Python requests、Go、PHP 或 PowerShell 代码。