Go x/crypto/bcrypt：生成密码哈希时使用自定义盐

有志者，事竟成！如果你在学习Golang，那么本文《Go x/crypto/bcrypt：生成密码哈希时使用自定义盐》，就很适合你！文章讲解的知识点主要包括，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

我正在尝试为 Go 服务器实现一个基本身份验证系统，该系统由具有多个服务器生成的密码（本质上是令牌）的用户组成，这些密码必须安全地存储在数据库中。

实现这一目标的一种方法是使用单向函数和全局唯一的盐对密码进行哈希处理。

但是，由于在我的例子中用户有多个密码，这会造成身份验证问题；每个用户的密码可能有不同的盐，因此服务器需要迭代数据库中的密码，使用与数据库中相同的盐对提供的密码进行哈希处理，然后进行比较。这似乎效率不高。

或者，我认为我可以放宽对盐的“全局唯一”约束，并在创建用户时随机生成盐，并将其用于该用户的所有密码。这样，我只需对用户提供的密码进行一次哈希处理，然后就可以使用 SQL 查询来执行身份验证。这也是相关问题中建议的解决方案。

但是，Go x/crypto/bcrypt 包不会公开使用自定义盐对密码进行哈希处理的函数，其盐生成是私有的。这是有充分理由的吗？这种对所有用户密码使用普通盐的方法是否存在漏洞？

考虑到像 GitHub 和 GitLab 这样的网站必须处理其个人访问令牌存储，这个问题似乎很常见，但 GitLab（默认情况下）似乎只是对其生成的令牌执行 sha256 哈希。

正确答案

根据设计，每个哈希都有自己的盐，它存储在数据库中。作为带有盐、密码散列、bcrypt 通行证等的字符串。似乎所有或大多数较新的一代加密技术都这样做，因此每个散列都必须单独破解。如果您希望在代码中存储某些内容，我会在每个密码中添加一个胡椒，然后让它们的盐在数据库中是唯一的。

您担心迭代每个密码的效率，但我不会，安全性可能比您的登录效率更好。只需将他们的登录会话存储 x 天？

是否存在漏洞

嗯，是的，如果这是一个答案，bcrypt 本身就被认为是脆弱的？

我认为你应该选择 argon2id，因为它今天被认为是“好的”，而且你的程序是新的 https://pkg.go.dev/golang.org/x/crypto/argon2 这是一个包装器，因此就 Go 加密而言，它是安全的，并且非常易于使用： https://github.com/alexedwards/argon2id

如果您想要令牌，您可能应该使用 UUID

本篇关于《Go x/crypto/bcrypt：生成密码哈希时使用自定义盐》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注编程网公众号！