在对用户密码进行散列之前添加一个常量字符串会使其更安全吗？

Posted 2023-02-24

【中文标题】在对用户密码进行散列之前添加一个常量字符串会使其更安全吗？

【英文标题】：Does adding a constant string to the user's password before hashing it make it more secure?

【发布时间】：2011-07-20 14:20:10

【问题描述】：

在散列之前将存储在代码中的常量字符串添加到密码中是否会使攻击者更难找出原始密码？

这个常量字符串是对盐的补充。所以，Hash(password + "string in code added to every password" + randomSaltForEachPassword)

通常，如果攻击者获得数据库，他们可能会通过暴力破解某人的密码。该数据库包含与每个密码对应的盐，因此他们将知道用什么来对他们的蛮力尝试进行加盐。但是，使用代码中的常量字符串，攻击者还必须获取源代码才能知道在他们的每次蛮力尝试中附加什么内容。

我认为它会更安全，但我想了解其他人的想法，并确保我不会无意中降低安全性。

【参考方案1】：

鉴于您已经有一个随机盐，附加一些其他字符串既不会增加也不会降低安全级别。

基本上，这只是浪费时间。

更新

使用 cmets 有点长。

首先，如果攻击者拥有数据库并且您唯一加密的是密码，那么无论如何游戏都会结束。他们拥有真正重要的部分数据。

其次，加盐意味着他们必须创建一个更大的彩虹表来包含更大的密码长度可能性。根据盐的长度和饼干可用的资源，这花费的时间变得不切实际。有关更多信息，请参阅此问题： How to implement password protection for individual files?

更新 2 ;)

确实，用户会重复使用密码（正如一些最新的被黑网站所揭示的那样），您希望防止数据丢失对他们造成影响是件好事。但是，一旦您阅读完此更新，您就会明白为什么这不是完全可能的。

其他问题必须一起考虑。盐的全部目的是确保相同的两个密码产生不同的哈希值。每个盐值都需要创建一个包含所有密码哈希可能性的彩虹表。

因此，不使用盐值意味着可以引用单个全局彩虹表。这也意味着，如果您对网站上的所有密码只使用一个盐值，那么他们可以再次创建一个彩虹表并一次获取所有密码。

但是，当每个密码都有一个单独的盐值时，这意味着他们必须为每个盐值创建一个彩虹表。彩虹表需要时间和资源来构建。有助于限制创建表所需时间的事情是了解密码长度限制。例如，如果您的密码必须在 7 到 9 个字符之间，那么黑客只需计算该范围内的哈希值。

现在盐值必须可用于对密码尝试进行哈希处理的函数。一般来说，你可以在别处隐藏这个值；但坦率地说，如果他们窃取了数据库，那么他们将能够很容易地追踪到它。因此，将值放在实际密码旁边对安全性的影响为零。

添加一些额外的字符所有密码都通用。一旦黑客破解了第一个，很明显其他人也有这个值，他们可以相应地编写他们的彩虹表生成器。这意味着它基本上不会节省时间。此外，它还会导致您产生错误的安全感，从而导致您做出错误的选择。

---

这让我们回到了加盐密码的目的。目的不是让它成为不可能，因为任何有时间和资源的人都可以破解它们。目的是使它变得困难和耗时。耗时的部分是让您有时间检测入侵，通知您必须通知的每个人，并在系统中强制更改密码。

换句话说，一旦数据库丢失，则应通知所有用户，以便他们可以采取适当的措施来更改您和其他系统上的密码。盐只是在为您和他们争取时间。

我之前提到破解密码“不切实际”的原因是，问题实际上是黑客确定密码的价值与破解密码的成本之间的关系。使用合理的盐值，您可以将计算成本提高到足以让很少有黑客会打扰的程度。他们往往是低调的人；除非你有理由成为目标。此时您应该研究其他形式的身份验证。

【讨论】：

你确定吗？ salt存储在数据库中，因此如果攻击者拥有数据库，那么他们就知道每个密码的salt。但是有了代码中的字符串，攻击者是否也需要获取源代码（或通过其他方式弄清楚字符串是什么）？

1 - 不泄露用户密码也很重要。用户经常在许多不同的网站上使用相同的密码，如果我的网站被黑客入侵，我不希望黑客能够获得用户的密码。 2 - 您能否提供链接或对此进行详细说明？盐是出现在密码中的已知值... 3 - 有盐意味着彩虹表没有用，这意味着每个用户的散列密码必须分别进行暴力破解。这需要更长的时间，但仍然可以通过这种方式检索密码。

“第二，现在我想起来了，每个密码中都有一个已知值实际上会降低你的安全性。” - 不，不会。

【参考方案2】：

这仅在您的威胁模型包含攻击者以某种方式获取您的密码数据库但无法读取存储在您的代码中的密钥的情况下才有帮助。对于大多数人来说，这种情况不太可能发生，因此不值得考虑。

即使在这种有限的情况下，它也不会为您带来很多额外的安全性，因为攻击者可以简单地获取他们自己的密码，并遍历所有可能的密钥值。一旦他们找到了正确的密码（因为它正确地散列了他们自己的密码），他们就可以像往常一样使用它来攻击数据库中的所有其他密码。

如果您担心安全地存储密码，您应该使用像 PBKDF2 这样的标准方案，它使用密钥拉伸来降低暴力破解的实用性。