破解加盐密码哈希的时间复杂度是否大于破解未加盐密码哈希的时间复杂度？答案

【问题标题】：Is the time complexity to crack a hash of a salted password greater than the time complexity to crack a hash of an unsalted password?破解加盐密码哈希的时间复杂度是否大于破解未加盐密码哈希的时间复杂度？
【发布时间】：2014-01-17 18:11:27
【问题描述】：

假设有人试图通过蛮力破解泄露的密码（即不使用彩虹表或常用密码列表），以下是否属实？

O(cracking_salted_password) > O(cracking_just_password)?

如果攻击者成功地访问了我的用户数据库，他们显然也有在对我的用户密码进行哈希处理时使用的盐，即使它对于每个用户来说都是完全唯一的。我想知道当有人试图通过暴力破解加盐密码时，时间复杂度是否也起作用。

【问题讨论】：

这真的没有意义。 Big-O 表示法（以及一般的时间复杂度）在n 的某个函数上运行，其中n 是指示问题大小的某个参数。您真的只是在问“‘破解’加盐密码是否需要更长的时间？”。
另外，从这个意义上说，你的意思是“破解”还不清楚。你的意思是找到哈希冲突的时间？
@OliCharlesworth 我的问题中的 n 是 password_guess+salt 的长度。我从 twalberg 那里得到了答案。

标签： encryption passwords time-complexity salt

【解决方案1】：

我想知道当有人试图通过暴力破解加盐密码时，时间复杂度是否起作用。

不，单个密码的时间复杂度不会因盐而大大增加。盐确实会增加加密时间的一个微小的常数，但不足以引起问题。

这并不意味着加盐是没用的。加盐有两个重要原因：

1) 使用相同密码的用户看起来会有所不同。如果攻击者看到多个用户有相同的密码，他/她会认为密码不是随机的，并首先攻击该密码。

2) 它使彩虹桌变得不切实际。

以前，您只需要一个查找表来查找所有密码猜测。您可以离线预先计算（甚至在某些系统之间重复使用它！）。

但是当您添加盐时，攻击者需要每个用户一个 Rainbow 表。这使得 Rainbow Tables 呈指数级增长，甚至可以让使用蛮力而不是使用 Rainbow Tables 更快！

因此，如果您只有一个用户，salt 可能无济于事，但是当您获得更多用户时，salt 是必不可少的。总是有盐会更好，因为小系统通常会变成大系统。

【讨论】：

很好的答案，使用像 BCrypt 这样的迭代密钥派生函数，散列密码的额外时间甚至都不小。

【解决方案2】：

由于加盐实际上只创建特定数量的不同值，特定明文散列到（即代替密码“密码”散列到值 X1，例如，使用 16 位盐，有 65536 种不同的可能它可以散列到的值），加盐的效果实际上只是改变方程中的常数乘法因子。换句话说，如果你的哈希算法是O(n^2)，那么对输入进行加盐处理就变成了k * O(n^2)，这实际上和O(n^2) 是一样的。是的，匹配特定密码的哈希将花费更多时间，最多可以提高您的盐的大小，但它确实不会改变O() 复杂性度量。复杂性度量不是关于执行某个问题需要多长时间；与原始问题相比，解决两倍大小的问题需要多长时间。

【讨论】：

不是真的，盐不是秘密，所以攻击者不必猜测。
@GregS 在许多情况下，这是正确的。最初的问题不清楚“破解者”是否可以访问盐，所以我做了假设（可能是错误的），他们可以访问的只是哈希......

【解决方案3】：

如果有一个数据库有几十个密码作为散列，并且通过散列一组（大）可能的值来进行攻击，从而产生这些散列，那么这项工作可以一次应用于多个散列

但是，如果密码是加盐的，那么每个密码都是唯一的，并且需要为每个密码重复工作

【讨论】：