Does adding a constant string to the user's password before hashing it make it more secure?
在散列前向密码添加存储在代码中的常量字符串是否会使攻击者更难确定原始密码？
这个常量字符串是加盐的。所以，
通常，如果攻击者得到了数据库，他们可能会用暴力破解出某人的密码。数据库包含与每个密码对应的salt，这样他们就知道用什么来限制他们的蛮力尝试。但是，使用代码中的常量字符串，攻击者还必须获取源代码，才能知道在每次暴力尝试之后要附加什么。
我认为它会更安全，但我想得到其他人的想法，也要确保我不会无意中使它变得不安全。
假设您已经有了一个随机的salt，那么附加一些其他字符串既不会增加也不会减少安全级别。
基本上，这只是浪费时间。
更新
使用这些评论的时间有点长。
首先，如果攻击者拥有数据库，而您唯一加密的就是密码，那么无论如何都要进行游戏。他们拥有真正重要的数据。
第二，salt意味着他们必须创建一个更大的彩虹表来包含更大的密码长度的可能性。这需要的时间变得不切实际，取决于盐的长度和饼干可用的资源。有关更多信息，请参阅此问题：如何对单个文件实施密码保护？
更新2；)
的确，用户会重复使用密码(正如一些最新的黑客网站所揭示的那样)，而且您希望防止数据丢失影响到密码。然而，一旦你读完这个更新，你就会明白为什么这不完全可能。
其他问题必须结合在一起。salt的全部目的是确保相同的两个密码产生不同的哈希值。每个salt值都需要创建一个包含所有密码散列可能性的彩虹表。
因此，不使用salt值意味着可以引用单个全局彩虹表。它还意味着，如果您只对站点上的所有密码使用一个salt值，那么，同样，它们可以创建一个彩虹表，并一次获取所有密码。
但是，当每个密码都有一个单独的salt值时，这意味着它们必须为每个salt值创建一个彩虹表。彩虹表需要时间和资源来构建。有助于限制创建表所需时间的是了解密码长度限制。例如，如果密码必须在7到9个字符之间，那么黑客只需计算该范围内的哈希值。
现在，salt值必须对要散列密码尝试的函数可用。一般来说，您可以将这个值隐藏在其他地方；但坦率地说，如果他们窃取了数据库，那么他们就可以很容易地跟踪到它。因此，将值放在实际密码旁边对安全性没有影响。
在所有密码中添加一个常见的额外字符对混合没有任何影响。一旦黑客破解了第一个，很明显其他人有这个值，他们可以相应地对彩虹表生成器进行编码。这意味着它基本上不会节省时间。而且，它会导致你的安全感错误，这会导致你做出错误的选择。
这让我们回到了加盐密码的目的。目的不是让它成为不可能，因为任何有时间和资源的人都能破解它。这样做的目的是让它变得困难和耗时。耗时的部分是让您有时间检测入侵，通知所有必须通知的人，并在系统中强制更改密码。
换句话说，一旦数据库丢失，就应该通知所有用户，以便他们可以采取适当的措施来更改您和其他系统上的密码。盐只是为你和他们争取时间。
我之前提到的破解密码"不切实际"的原因是，问题实际上是黑客决定密码的价值与破解密码的成本。使用合理的salt值，您可以将计算成本提高到很少有黑客会麻烦的程度。他们往往是低挂水果类的人；除非你有理由成为目标。在这一点上，您应该研究其他形式的身份验证。
只有当您的威胁模型包含这样一种情况时，攻击者才能以某种方式获取您的密码数据库，但无法读取存储在代码中的密钥，这才会有所帮助。对大多数人来说，这不是一个极有可能发生的情况，因此不值得为其提供餐饮服务。
即使在这种有限的情况下，它也不会为您带来大量额外的安全性，因为攻击者可以简单地获取自己的密码，并迭代所有可能的密钥值。一旦他们找到了正确的密码(因为它正确地散列了他们自己的密码)，他们就可以像往常一样使用它攻击数据库中的所有其他密码。
如果您关心安全地存储密码，那么您应该使用一个标准的方案，比如pbkdf2，它使用密钥拉伸来降低暴力强制的实用性。