在散列之前向用户的密码添加常量字符串是否更安全?

Kyl*_*yle 1 security passwords hash cryptography

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

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

通常情况下,如果攻击者获取数据库,他们可能会通过蛮力找出某人的密码.该数据库包含与每个密码相对应的盐,因此他们知道如何对其强力尝试加盐.但是,使用代码中的常量字符串,攻击者还必须获取源代码才能知道要对每个强力尝试添加什么.

我认为它会更安全,但我想得到其他人的想法,并确保我不会无意中使其不那么安全.

Not*_*tMe 5

鉴于您已经有一个随机盐,附加一些其他字符串既不会增加也不会减损安全级别.

基本上,这只是浪费时间.

更新

使用这些评论的时间有点长.

首先,如果攻击者拥有数据库并且您加密的唯一内容是密码,那么游戏无论如何.他们拥有真正重要的数据.

其次,盐意味着他们必须创建一个更大的彩虹表来包含更大的密码长度可能性.根据盐的长度和裂解装置可用的资源,这种时间变得不切实际.有关更多信息,请参阅此问题: 如何实现单个文件的密码保护?

更新2 ;)

确实,用户重复使用密码(正如一些最新的黑客网站所揭示的那样),并且您希望防止数据丢失影响它们.但是,一旦您阅读完此更新,您就会明白为什么这不完全可能.

其他问题必须合在一起.salt的全部目的是确保相同的两个密码导致不同的哈希值.每个salt值都需要创建一个包含所有密码哈希可能性的彩虹表.

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

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

现在,salt值必须可用于散列密码尝试的函数.一般来说,你可以在别处隐藏这个值; 但坦率地说,如果他们偷了数据库,那么他们就能很容易地追踪它.因此,将值放在实际密码旁边对安全性没有任何影响.

添加所有密码通用的额外字符不会增加任何混合.一旦黑客破解第一个,很明显其他人都有这个价值,他们可以相应地编码他们的彩虹表生成器.这意味着它基本上不会浪费时间.此外,它会导致您的安全感错误,这可能导致您做出错误的选择.


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

换句话说,一旦数据库丢失,应通知所有用户,以便他们可以采取适当的措施更改您和其他系统上的密码.盐只是给你买,他们有时间做这件事.

之前我提到"不切实际"的原因是关于破解它们的问题实际上是黑客确定密码的价值与破解密码的成本之一.使用合理的盐值可以大大提高计算成本,很少有黑客会这么做.他们往往是低垂果的人; 除非你有理由成为目标.此时,您应该研究其他形式的身份验证.