我们有一个与移动前端通信的 REST API。提交一次性密码后，后端将发出一个令牌（随机 UUID v4 字符串）供移动应用程序用作后续请求的身份验证。服务器将与用户一起将该令牌的散列版本存储在数据库中。
我们希望确保验证令牌花费尽可能少的时间。
问题
什么样的散列/加密足以将令牌存储在数据库中？像 SHA256 这样的快速哈希是否足够好，或者我们应该使用像 bcrypt 这样的慢速哈希？如果使用 SHA256，我们是否需要包含盐，因为原始的未散列令牌只是一个随机的 16 字节 UUID？
使用哪种散列方法在数据库中存储 REST API 令牌？
信息安全
哈希
会话管理
休息
api
sha256
2021-08-14 11:19:22
1个回答
TLDR；SHA256 够用了
为了回答这个问题，我们首先需要看看为什么要加盐、散列和使用散列的多次迭代；
我们为什么要加盐？保护密码熵较弱的用户的密码不被破解（例如彩虹表或两个密码相同的用户）。这不是问题，因为 UUID4 将具有 122 位的熵1。
如果我们想创建一个包含所有已被 SHA256 散列的 UUIDv4 值的彩虹表，我们可以每秒执行 1 万亿次散列2。制作彩虹表需要168.6 万亿年。所以我们不需要担心这个。
我们为什么要散列？防止存储密码的明文副本。这似乎是个好主意。您不希望可以读取您的数据库3的人能够模拟用户。
为什么我们使用多次迭代？减缓蛮力攻击。如前所述，UUID4 将具有 122 位的熵。即使在高速下破解这些哈希也是不可行的。
[1] 128 位 -预先确定的 6 位
[2] 当前最快的哈希率一直在链接，所以我不会费心去寻找最新的速度，它会在几个月内过时。
[3] 这可能是 SQL 注入，或从备份中泄露的副本，或内部人员，或其他任何东西。
其它你可能感兴趣的问题