强制使用复杂密码是否比添加密码“更重要”?

salt的要点是攻击者不能再使用salt 预先存在的 字典来攻击系统中的任何用户。他们必须为使用该用户的salt的每个用户创建一个全新的词典,这需要时间和精力。如果您在为系统的所有用户创建字典之前就了解到违规行为,那么您就有时间采取行动。(提醒用户其登录凭据 必须

,真的)你的用户会容忍的。尽管如此,盐渍还是一项基本的安全措施,没有盐渍你真的负担不起。

保持适当的水分比呼吸更重要吗?

我倾向于对大多数网站使用salt/用户、全局salt(salt/算法)和适度的密码复杂度规则(8个以上字符,至少有2个大写/数字/标点符号组合)的方法。使用SALT需要为每个想要打破的帐户生成一个彩虹表——假设每个用户具有唯一的SALT。使用全局salt需要同时危害数据库和应用程序服务器。在我的例子中,这总是两个独立的系统。使用密码复杂性规则有助于防止使用简单、易于猜测的密码。

对于具有更多权限的帐户,您可能希望强制执行更高的密码复杂性。例如,我们的广告林中的管理员必须拥有至少15个字符的密码。它实际上比较短的密码更容易,因为它几乎迫使您使用密码短语而不是密码。

您还希望指导用户如何创建良好的密码,或者更好地说,如何传递短语,并了解各种社会工程攻击,这些攻击绕过了所有保护数据的技术手段。

好的,让我们看看真实的数字:

单个Nvidia 9800GTX每秒可以计算3.5亿MD5哈希。按照这种速度,小写和大写字母数字字符的整个键空间将在7天内完成。7个小时,两个小时。根据您的算法,使用盐渍的次数只能增加一倍或三倍。

请注意,我在这里谈论的是暴力,因为在这种复杂程度之后,预映像攻击可能适用,也可能不适用。

现在,如果你想防御专业攻击者,他们没有理由不能每秒获得1万亿哈希,他们只会使用专用硬件或廉价GPU机器,以较便宜的为准。

看,密码散列的问题是,它只会减少时间,直到你徒劳的厄运。如果你想要什么 真正地 强大,但仍然像存储的哈希密码一样幼稚,选择PBKDF2。

还有一个问题,用户是否会使用你强迫他在所有其他网站上使用的“强”密码?如果他不将它们保存在主密码文件中,他肯定会。而那些其他站点不会使用与您使用的相同的强散列算法,从而破坏了您系统的用途。我真的看不见 为什么? 如果不是为了阻止用户在多个站点上使用相同的密码,那么你希望你的散列是超级强大的;如果攻击者可以访问您的哈希值,则您很可能已经丢失了。

另一方面,我将重复一次又一次地向人们提问他们的哈希方案有多“安全”,只要使用客户端证书,所有问题都会得到解决。用户不可能在多个站点上使用相同的凭据,攻击者无法在不修改您的凭据的情况下破坏您的凭据,如果用户将凭据存储在智能卡上,则他们的凭据很难被盗,等等。

天真地回答你的问题:强密码只由强哈希算法支持。

除了对长字符串的要求之外,每个约束 减少 密码相空间的大小。约束会导致 减少 在复杂性上,不是增加。

坚持长传短语,使用盐渍,没有其他限制。

当人们说“复杂的”技术时,他们通常指的是复杂的。转换可能非常复杂,但又是可交换的,不幸的是,如果您不知道这意味着什么,那么您就无法评估该技术的优点。算法的复杂性只会通过模糊性提供安全性,这有点像是把房子搬出城镇而不锁门。

但不要妨碍你的用户。提出建议,但不要妨碍他们。

这取决于你的用户选择好的密码。您可以建议如何选择好的密码,接受任何给定的密码,并在给定密码允许的情况下确保用户信息的安全。

盐密码和复杂密码都是真正安全所必需的。通常,rainbow表不是动态创建来攻击特定站点的,而是预先计算的。简单地强制输入密码比根据特定的salt值生成查找表要有效得多。

也就是说,散列的目的是确保攻击者在数据库受损时无法恢复密码。它无法阻止攻击者猜测简单的密码。

因此,在我看来,无论您的网站的安全级别如何,盐渍都是强制性的。强制密码复杂性对于高安全性站点来说是很好的,但肯定更具情境性。它不能保证你的用户有良好的安全措施。我还要补充一点,对于一个不需要安全密码的站点,需要一个安全密码可能弊大于利,因为用户很可能会回收他们在其他更重要的站点上使用的高安全密码。