提高基于web登录的安全性

4使用AES加密salt,密钥仅对进行身份验证的应用程序可用
5多次修改密码

这些步骤仅影响密码文件(DB列)被盗且攻击者可见的情况。nonce只会击败预哈希(彩虹表),但这仍然是一件好事,应该保留。

(同样,假设您正在尝试最小化受损数据库的影响。)加密nonce意味着攻击者有额外的暴力步骤,但您没有说明nonce的加密密钥存储在何处。很可能可以安全地假设,如果数据库被破坏,nonce将是明文的,或者只是简单地解密。因此,攻击者的努力再次成为针对每个散列的暴力。

不管你的密码组成要求如何,用户仍然可以做出“更容易猜测”的密码P@ssw0rd公司“这符合规则。所以,暴力很可能在任何情况下对某些用户群体取得成功。(我的意思是强调采取措施防止泄露密码。)

答案可能在某种程度上取决于网站的性质、用户和攻击者。例如,它是那种黑客可能会针对特定帐户(也许是“管理员”帐户)的网站,还是一个他们只想得到尽可能多的帐户?用户的技术水平如何?他们保持自己帐户安全的动机如何?在不知道答案的情况下,我会假设它们不是技术性的,也没有动机。

5) 多次重新设置密码。 这可以显著降低所有暴力攻击的速度-哈希值降低1000倍,暴力攻击速度降低1000倍。

如何使其仅对应用程序可用?它必须存储在某个地方,如果应用程序受到攻击,攻击者很可能会得到它。可能会有一些直接针对DB的攻击,这会产生影响,所以我不认为这是无用的,但这可能是不值得的。如果您确实这样做了,那么您最好加密密码本身和数据库中的任何其他敏感数据。

如果您只关心密码,那么是的,这将是实现与4)相同结果的更好方法,当然,它非常容易实现。

无效措施

3) 将nonce大小从32字节增加到64字节。 计算彩虹表对于任何salt都是完全不切实际的,因此这只会在攻击者不知道salt的情况下产生影响。然而,如果他们可以得到散列密码,他们也可以得到盐。

将密码长度增加到8以上不会对暴力时间产生实际影响。

2) 强制用户更改密码

1. 增加密码长度会给密码增加一些熵。
2. 要求频繁更改密码通常会迫使用户使用不太安全的密码。他们需要在5月、6月、7月弄清楚密码是什么。一些@05x, 一些@06x, 一些@07x。
3. 不能肯定,但我希望密码长度在您的情况下更重要。

您可以允许密码短语来缓解密码长度问题。

http://research.microsoft.com/en-us/um/people/cormac/papers/2009/SoLongAndNoThanks.pdf

增加密码长度和强制使用更复杂的密码会导致站点/应用程序之间重复使用一个或两个密码以及写下密码,从而降低安全性。

对于现有的:

e1:我知道你是从哪里来的,但这些规则相当苛刻——它当然增加了安全性,但以牺牲用户体验为代价。正如vulkanino提到的,这将阻止一些用户(取决于您的受众-如果这是一个intranet应用程序,他们别无选择。。。但他们的显示器上会有一个带有密码的黄色粘胶——清洁工和办公室闲逛者将是你最大的问题)。

e2:这是一个开始,但您可能应该检查一个坏密码列表(例如:“password”、“qwerty”、网站URL)。。。网上有几个列表可以帮你解决这个问题。考虑到你的 e1级

e4:Unique salt防止使用同一密码识别多个用户,但是还有其他方法使其唯一-例如,使用用户名作为辅助salt+哈希。

e5:很可靠,虽然TLS内置了后备功能,但低端TLS协议并不十分安全,因此您可能需要检查您是否不允许这些连接。

n1+n2: 已经够痛苦了。

n3:没有明显的好处

n4:没有明显的好处-无论加密过程是什么,代码中都可以使用,因此也可能会受到影响。也就是说,除非你的数据库和应用服务器是两台不同的机器,它们都是为自己的任务而强化的——在这种情况下,你可以避免使用密码存储的任何东西都会在数据库受损的情况下有所帮助(在这种情况下,从数据库中删除唯一的salt会有所帮助)。

其他要点:

• 您的安全性仅与存储和处理它的系统一样好。任何可能被破坏的系统,或者已经有后门的系统(想想:可以访问系统的用户数量——服务器管理员、DBA、编码员等等)都是一个薄弱环节。

• 应用程序中的攻击检测脚本可能是有益的—但您应该注意拒绝服务(DoS)攻击。跟踪失败的登录和来源是一个很好的开始-但要知道,如果你锁定帐户在5失败,有人可能会拒绝一个已知的帐户(包括管理员帐户)。无法使用该应用程序可能与失去对您帐户的控制一样糟糕。多重散列( n5号 )减慢这个过程,选择一个较慢的散列算法也是一个很好的步骤,也许构建重新尝试延迟也会有帮助(第一次失败时1秒,第二次失败时2秒,等等),但是同样要注意DoS。您可能需要过滤两个基本内容:(1)来自同一源/IP的多个攻击(放慢速度,最终阻止来自该IP的访问-但只是暂时的,因为它可能是合法用户)可能需要进一步测试多组多个攻击。(2) 来自不同IP的多重攻击-第一种方法仅锁定单个用户/源,但如果有人使用机器人网络或匿名服务,则需要查找其他类型的可疑活动。

我不认为这些东西可以提高你的密码安全性。存储在数据库中的密码的安全性只有在您希望有人获得数据库副本时才相关。在数据库中使用(感知到的)更强的散列函数只会混淆应用程序。事实上,一个咸MD5就可以了(我知道MD5上有攻击,我不相信它们中的任何一个与密码散列有关)。

您最好放松密码规则以获得更好的安全性,因为如果您至少需要一个上下拉丁字母,则可以有效地强制非拉丁键盘用户使用外来字母(尝试在西里尔键盘上键入上下拉丁字母)。这使得他们更有可能把它写下来。

最好的安全措施是避免全部使用密码。如果是公司中使用ActiveDirectory的企业应用程序,请考虑委派身份验证,而不是编写自己的身份验证。其他方法可以包括使用信息卡,让您的应用程序声明知道。

用MD5/SHA加密客户端浏览器中的密码,然后在服务器端将散列作为用户密码。这样,当密码通过SSL/TLS传输时,它就不会是纯文本的,在服务器上也永远不会是纯文本的。因此,即使它在任何时候被黑客窃取(中间人,服务器/数据库黑客),它也不能被用来获得访问权限 其他