密码哈希字符串编码没有标准格式。一种常见的约定是使用 "$" 分隔符，但它并不适用于所有哈希算法。例如，bcrypt 省略了 "$" 分隔符，而 argon2 使用全名标识符和五个字段。由于缺乏标准化，一些旧系统可能只检查哈希值的第一个字符来识别算法。

我询问密码经过哈希处理并准备存储后使用的格式。美元符号 $ 注释似乎很普遍。标准中是否对此进行了描述（包括算法的标识符）？

例如，当将 go 与 golang.org/x/crypto/bcrypt 一起使用时，它会给出这样一个编码字符串（演示）：

func main() {
    h, err := bcrypt.generatefrompassword([]byte("foo"), bcrypt.defaultcost)
    if err != nil {
        panic(err)
    }

    fmt.printf("%s", h)
    // output: $2a$10$g1d5kuvdirrouywl2bqs7ulowczlm.zqbrm8o364u20p20ynmj.ve
}

但是，其他哈希包（例如 scrypt（示例）和 argon2）仅返回生成的哈希值。使用 argon2 shell 命令，返回一个编码字符串：

echo "foo" | argon2 saltsalt
type:           argon2i
iterations:     3
memory:         4096 kib
parallelism:    1
hash:           d9e4f94546b9e5b0cfb2dbf9dad81d41371845d8b6a8c25ce7caf23e13f1ef72
encoded:        $argon2i$v=19$m=4096,t=3,p=1$c2fsdhnhbhq$2et5rua55bdpstv52tgdqtcyrdi2qmjc58ryphpx73i
0.005 seconds
verification ok

我找到了一篇 go / argon2 特定博客文章解释了这种编码，到目前为止还不错

我发现的变体

我的麻烦在于美元分隔字符串的定义、我发现的可移植性和变化。

glibc

man 3 crypt 页面提供了一些指示。有一个标识符表：

id   method
              ───────────────────────────────────────────────────────────
              1    md5
              2a   blowfish (not in mainline glibc; added in some linux
                   distributions)
              5    sha-256 (since glibc 2.7)
              6    sha-512 (since glibc 2.7)

但这不包括较新的类型，例如 argon2i 或 scrypt。

然后是示例字符串：

$id$salt$encrypted
$id$rounds=yyy$salt$encrypted

后者仅在 glibc 2.7 之后才受支持。

bcrypt

虽然 bcrypt 使用 glibc 中的 2a (blowfish) 标识符，但其编码似乎与上面的示例略有不同：

$2a$10$g1d5kuvdirrouywl2bqs7ulowczlm.zqbrm8o364u20p20ynmj.ve
$id$cost$<dot seperated line of what exactly?>

氩气

argon2 使用 5 个字段和一个全名标识符，例如 argon2

$argon2i$v=19$m=4096,t=3,p=1$c2FsdHNhbHQ$2eT5RUa55bDPstv52tgdQTcYRdi2qMJc58ryPhPx73I
$id$version$parameters$salt$encrypted

为什么？

我想编写一个包，以与算法无关的方式散列和验证密码。允许消费者更改参数和算法而无需重构其代码。因此，在验证过程中，包应该能够断言存储密码时使用的算法。如果存储的参数或算法版本与当前使用的不同，则密码将被重新散列并返回一个新的编码字符串。

作为奖励，我希望该软件包能够重新散列可能由旧（不可用）应用程序存储的“旧”密码。例如，md5。为了做到这一切，我想对存储格式本身有更深入的了解。

正确答案

密码哈希字符串编码的标准是什么？

没有。

嘿，这是一个简单的答案！ 点击“发布您的答案”。

好吧，虽然不幸的是上述陈述是正确的，但值得庆幸的是，有些人已经费尽心思收集了有关所有使用变化的大量信息。

特别是，Python Passlib 库的作者（它的作用与您想要做的事情本质上相同）已经写了一篇关于他们所谓的 Modular Crypt Format 的页面，他们称之为“不是一个标准”。以下是该页面的一些选择引用[粗体斜体强调我的]：

但是，没有官方规范文档描述这种格式。 也不存在标识符的中央注册表或实际规则。模块化的 crypt 格式更多的是一个临时的想法，而不是一个真正的标准。

[Modular Crypt Format – Overview]

不幸的是，这种格式没有规范文档。相反，它仅以事实上的形式存在

当 MCF 首次引入时，大多数方案选择单个数字作为其标识符（例如 $1$ 表示 md5_crypt）。因此，一些旧系统在尝试区分哈希值时仅查看第一个字符。

大多数模块化 crypt 格式哈希都遵循此约定，尽管有些（例如 bcrypt）省略了配置和配置之间的 $ 分隔符摘要。

[T]关于配置字符串是否末尾应包含尾随 $ 没有固定标准

[Modular Crypt Format – Requirements]

请注意，模块化加密格式不是规范或标准。它是对实际使用的各种不同格式的描述。 Password Hashing Competition (PHC) 的组织者试图制定一个规范，称为 PHC String Format。但是，PHC 并不是具有任何权威的正式标准组织。它只是一群松散的密码学家。虽然他们建议每个新的密码哈希函数都应使用 PHC 字符串格式，但他们只能强制提交给密码哈希竞赛的密码哈希函数。 p>

无论哪种方式，PHC 字符串格式仅适用于新的密码哈希函数，不适用于现有的密码哈希函数。

虽然我强烈建议您生成的任何输出都应该使用 PHC 字符串格式，但您仍然需要处理各种不同格式的输入，including some gems like these：

cta_pbkdf2_sha1 和 dlitz_pbkdf2_sha1 均使用相同的标识符。虽然还存在其他内部差异，但可以通过以下事实快速区分两者：cta 哈希值始终以 = 结尾，而 dlitz 哈希值根本不包含 =。

今天关于《什么是密码哈希字符串编码标准？》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！