在 django 密码字段中隐藏算法、迭代、盐答案

【问题标题】：Hide algorithm, iterations, salt in django password field在 django 密码字段中隐藏算法、迭代、盐
【发布时间】：2021-08-07 13:16:14
【问题描述】：

在 django 中，用户表密码使用安全算法 (pbkdf2_sha256) 自动加密，并带有盐和迭代。但我不明白的是为什么 django 密码字段以这种格式显示算法、迭代和盐： <algorithm>$<iterations>$<salt>$<hash>

我认为这些信息是秘密的，我只想显示哈希值。

【问题讨论】：

因为您可以使用不同的算法、迭代和盐。如果不指定这一点，Django 无法对密码执行相同的操作以查看哈希是否匹配。
但是显示盐和迭代安全吗？
通常你不应该暴露任何密码字段。但是如果我们使用盐，它会使搜索空间更大（特别是如果每条记录都有不同的盐）。
不，通常哈希函数被视为单向函数：这意味着计算哈希（非常）快，而找到一个项目x f(x) 是给定哈希的 只能通过穷举搜索来完成。
一个好的散列函数的想法是，即使完全了解盐等，您也无法有效地确定真正的密码。以 AES 加密为例：即使您知道通信是通过 AES 加密进行的，只要您没有私钥，您就无法有效地了解参与者在说什么关于，或者至少在撰写本文时，没有任何出版物声称它可以“破解” AES 加密。

标签： django

【解决方案1】：

我认为这些信息是秘密的，我只想显示哈希值。

从某种意义上说，你不应该暴露它是秘密的。但由于密码可以使用不同散列算法进行散列，该算法需要不同次迭代和不同盐，因此您无法匹配用密码散列。

确实，当 Django 想要检查密码是否匹配时，它需要执行精确的 same 散列（因此相同的算法、迭代次数和盐）来检查两个散列是否正确相同。因此，Django 需要此信息来检查哈希。

请注意，这里的盐每次都不同，因此通过添加盐，“搜索空间”呈指数增长，因此rainbow table attacks [wiki] 不太成功。此外，只要散列在某一方面很便宜，但只能通过在不同方向上的详尽搜索来确定，那么散列就是一种安全度量。

如果一个人不存储算法、迭代次数和盐每个用户，而只是将这些东西存储在一个文件中，那么我们使用相同的算法，具有相同的迭代次数和相同的每次加盐。在这种情况下，彩虹表攻击可能更有效。通过指定随机盐 per 记录并使用，我们让“搜索空间”随着盐的长度呈指数增长。

如果散列算法是one way function [wiki]，那么提供盐、算法和迭代次数等参数将不足以在没有指数搜索的情况下反向计算函数，这很昂贵并且很容易超出当前的可行范围技术水平。

【讨论】：