在散列之前将代码中存储的常量字符串添加到密码中会使攻击者更难找出原始密码吗？
这个常量字符串是盐的补充。所以，Hash(password + "string in code added to every password" + randomSaltForEachPassword)
通常情况下，如果攻击者获取数据库，他们可能会通过强力手段找出某人的密码。该数据库包含与每个密码相对应的盐，因此他们知道如何对其强力尝试加盐。但是，使用代码中的常量字符串，攻击者还必须获取源代码才能知道每次强力尝试附加什么。
我认为它会更安全，但我想得到其他人的想法，并确保我不会无意中使其不那么安全。
答案 0 :(得分：5)
鉴于您已经有一个随机盐，附加一些其他字符串既不会增加也不会减损安全级别。
基本上，这只是浪费时间。
<强>更新
使用评论的时间有点长。
首先，如果攻击者拥有数据库并且您加密的唯一内容是密码，那么游戏无论如何。他们拥有的数据是真正重要的部分。
其次，盐意味着他们必须创建一个更大的彩虹表来包含更大的密码长度可能性。根据盐的长度和裂解装置可用的资源，这种时间变得不切实际。有关详细信息，请参阅此问题： How to implement password protection for individual files?
更新2 ;）
用户重用密码确实是正确的（正如一些最新的黑客网站所揭示的那样），并且您希望防止数据丢失影响它们。但是，一旦您阅读完此更新，您就会明白为什么这不完全可能。
其他问题必须合在一起。 salt的全部目的是确保相同的两个密码导致不同的哈希值。每个salt值都需要创建一个包含所有密码哈希可能性的彩虹表。
因此，不使用salt值意味着可以引用单个全局rainbow表。这也意味着，如果您只对网站上的所有密码使用一个salt值，那么他们可以再创建一个彩虹表并一次获取所有密码。
但是，当每个密码都有一个单独的salt值时，这意味着他们必须为每个salt值创建一个彩虹表。彩虹表需要时间和资源来构建。有助于限制创建表所需时间的事情是知道密码长度限制。例如，如果您的密码必须在7到9个字符之间，那么黑客只需要计算该范围内的哈希值。
现在，salt值必须可用于散列密码尝试的函数。一般来说，你可以在别处隐藏这个值;但坦率地说，如果他们偷了数据库，那么他们就能很容易地追踪它。因此，将值放在实际密码旁边对安全性没有任何影响。
添加所有密码通用的额外字符 不会添加任何内容。一旦黑客破解第一个，很明显其他人都有这个价值，他们可以相应地编码他们的彩虹表生成器。这意味着它基本上不会浪费时间。此外，它会导致您的安全感错误，这可能导致您做出错误的选择。
这使我们回到了腌制密码的目的。目的不是让它变得不可能，因为任何有时间和资源的人都可以破解它们。目的是使其困难和耗时。耗时的部分是让您有时间检测中断，通知您必须的每个人，并在您的系统中强制执行密码更改。
换句话说，一旦数据库丢失，应通知所有用户，以便他们可以采取适当的措施更改您和其他系统上的密码。盐正在给你买，他们有时间做这件事。
之前我提到“不切实际”的原因是关于破解它们的问题实际上是黑客确定密码的价值与破解密码的成本之一。使用合理的盐值可以大大提高计算成本，很少有黑客会这么做。他们往往是低悬的水果类人;除非你有理由成为目标。此时，您应该研究其他形式的身份验证。
答案 1 :(得分：2)
这仅在您的威胁模型包含攻击者以某种方式获取您的密码数据库但无法读取存储在您的代码中的密钥的情况下才有用。对于大多数人来说，这不是一个非常可能的情况，所以它不值得为之服务。
即使在这种有限的情况下，它也不会为您带来额外的安全性，因为攻击者可以简单地获取自己的密码，并迭代所有可能的密钥值。一旦找到正确的密码（因为它正确地散列了自己的密码），他们就可以像往常一样使用它来攻击数据库中的所有其他密码。
如果您担心安全地存储密码，您应该使用像PBKDF2这样的标准方案，该方案使用键拉伸来使粗暴强制更不实用。