Go x/crypto/bcrypt生成密码哈希时自定义盐使用及安全问题

为什么x/crypto/bcrypt不开放自定义盐接口 #

• bcrypt的核心设计场景是存储用户自主设置的低熵人类记忆密码，这类密码普遍长度短、规律性强，极易被彩虹表、暴力枚举破解。强制为每次哈希生成全局唯一的随机盐、把盐生成逻辑封装为私有不可调用的方法，是刻意的API层面安全防护，从根源上避免开发者因图方便使用固定盐、弱盐，导致批量密码泄露的风险。
• bcrypt输出的哈希串本身已经内置了算法版本、cost参数、盐值信息，常规校验只需要传入用户输入的明文和数据库存储的哈希串即可完成比对，不需要单独存取盐值，黑盒封装完全匹配它的设计目标。

单用户所有密码共用同一盐的安全缺陷 #

• 这种设计存在明确的安全短板：一旦数据库发生泄露，攻击者拿到单个用户的固定盐后，就可以针对该盐预计算彩虹表，一次性批量破解该用户名下所有密码/令牌，不需要为每条凭证单独跑破解流程，攻击者的破解成本会被大幅拉低。
• 这种方案本质是把安全防护的粒度从「单条凭证」降级到了「单个用户」，只要某用户的盐泄露，该用户名下所有存储的凭证会全部失守，安全冗余度明显不足。

服务端生成令牌场景的最优实现 #

你提到的GitHub、GitLab这类平台的个人访问令牌存储场景，和用户自主设置密码的场景有本质区别，不需要硬套bcrypt的设计逻辑：

• 服务端生成的令牌本身是密码学安全的高熵随机值，长度通常在20字节以上，本身就对彩虹表攻击免疫——哪怕不加盐，攻击者暴力破解单个160位以上熵的随机令牌需要的算力成本，高到完全没有现实可行性，这也是GitLab默认仅使用SHA256哈希存储令牌的核心原因。
• 如果追求认证查询效率，可以直接采用适配该场景的实现方案：
  • 生成令牌时使用密码学安全随机数生成器产出至少16字节的随机令牌原文，仅在生成时返回给用户一次，服务端不存明文
  • 存储时直接对令牌原文做SHA256或SHA3-256哈希，不需要额外加盐，把哈希值设为数据库唯一索引
  • 认证时直接对用户提交的令牌做相同算法的哈希，通过SQL精确匹配哈希值即可完成校验，不需要遍历任何用户凭证记录，性能极高
• 如果需要同时兼容用户低熵登录密码+多个高熵访问令牌的场景，也不建议使用用户级固定盐：可以给每个凭证单独生成随机盐，同时在用户表中缓存最近一次使用的凭证哈希索引，绝大多数请求第一次SQL查询就能直接命中，只有缓存不命中时才遍历该用户的所有凭证做比对，兼顾安全和性能。

注意：不要把bcrypt、Argon2这类为低熵密码设计的慢哈希算法，直接套用到高熵服务端生成令牌的场景。慢哈希的核心作用是拉高低熵密码的暴力破解成本，对于本身熵值足够高的随机令牌来说，慢哈希只会平白增加服务端性能开销，不会带来实际安全收益。

内容的提问来源于stack exchange，提问作者Kyle Anderson