使用BCrypt哈希API令牌时存储明文前缀是否存在安全漏洞？

你描述的场景属于第一种情况：等效于采用25位字符的令牌，整体系统仍然具备合理的安全性，不属于安全演戏。

• 首先需要确认前提：只要你的30位API令牌是通过密码学安全的随机数生成器生成、不存在可预测规律，这个方案的安全性就完全成立。
• 明文存储前5位仅仅是泄露了固定的5位已知信息，攻击者拿到拖库的数据后，需要暴力破解的只有剩余25位随机字符。如果你的令牌采用大小写字母+数字共62种字符生成，25位对应的熵约为149bit，这个量级的熵本身就足以抵御现有技术下的所有暴力破解尝试。
• BCrypt是专门为敏感信息存储设计的慢哈希算法，你可以通过调整工作因子控制单次哈希计算的耗时，哪怕攻击者拿到了完整的哈希值，每秒最多也只能完成几千到几万次哈希计算，想要遍历25位随机字符的所有可能性，所需时间长达数万年甚至更久，完全不存在“轻易破解”的可能。
• 这种设计已经被行业广泛验证，GitHub、GitLab等主流平台的个人访问令牌都采用了类似逻辑：公开前若干位方便用户识别，剩余部分哈希后存储，没有出现过因此导致的安全漏洞。

• 不要为了抵消前缀泄露的长度刻意降低令牌总长度，保持30位的总长度即可，额外的熵可以提供更高的安全冗余。
• 生成令牌时必须使用框架提供的密码学安全随机接口，不要使用普通的非安全随机数函数，避免令牌本身存在可预测性。

内容的提问来源于stack exchange，提问作者Toms Mikoss