2010-08-19 29 views
3

我刚刚读到一篇文章说7个字符的密码不再安全。但是,如果服务器在每次登录尝试后都增加重试登录尝试的时间,那么强力攻击就毫无用处。你如何在asp.net中创建这样的逻辑?不知何故,我猜服务器端代码需要记住试图登录的IP地址,并应增加每次新尝试的响应时间?暴力破解在asp.net登录失败保护

+1

7个字符?您至少需要9个字符,包括符号。 – erickson 2010-08-19 19:40:57

回答

4

IP地址确实不是一种识别用户的安全方法。您可以尝试将上次登录尝试的时间存储在cookie中,但如果浏览器不接受它们,则它的使用将受到限制。会话变量也需要cookie,所以它们没有了。

有些网站(雅虎想到)在第三次尝试之后开始显示验证码表单。除了您的登录信息外,您还必须正确回答验证码。

另一种选择是在X失败尝试(可以在数据库中跟踪)后禁用帐户,但我个人不喜欢这样做,因为它往往会迫使我在某人忘记密码时强制重设密码。

+0

嗯,我该怎么把这个。想象一下,有人试图使用登录页面登录,但一些代码尝试每次登录。然后我猜,在服务器端,您需要记住下次需要验证码时。很难解释我的问题。 – 2010-08-19 19:30:34

+0

如果您担心蛮力攻击,您可以每次都显示验证码。但是,在给定窗口中尝试过多次后锁定帐户对于大多数网站来说是完全足够的。如果您需要比普通网站更高的安全性,那么比阻止对密码的暴力攻击还有很多。看看OWASP--还有很多其他类型的攻击,比如CSRF和XSS,这些攻击对每个Web应用程序都是严重的威胁。 – saille 2010-08-19 22:38:00

+0

当您的帐户被锁定时,您不一定需要联系某人。如何通过电子邮件向您发送链接以解锁您的帐户的系统? – saille 2010-08-19 22:56:20

2

许多蛮力攻击都是离线发生的。这就是为什么失败尝试锁定无法替代需要复杂的密码,使用适当的“盐”和加强键。

+0

也许一个愚蠢的问题:但是应该如何破解我的ASP.NET应用程序离线? 答案是,ASP.NET身份验证在尝试失败后会查看您的帐户。也可能是一个解决方案,不是吗?假设没有脱机破解:-) – Remy 2010-08-19 20:13:50

+3

假设一位员工拿着磁带和用户数据库的备份。 – erickson 2010-08-19 20:30:04

2

ASP.NET有一个内置机制来防止对登录密码进行暴力攻击。 请参阅maxInvalidPasswordAttempts Membership property

恕我直言7字符密码完全适用于大多数Web应用程序(我的银行允许7个字符密码)提供安全最佳实践,如安全地哈希密码和阻止暴力攻击。

一旦你超过了7或8个字符的密码,你确实在说“我的应用程序需要超级安全”,在这种情况下,你应该考虑单独的客户端SSL证书。在密码中需要更多字符的回报递减。有多少用户可以记住复杂的8或9个字符的密码?他们最终写下来。就我个人而言,任何需要我创建一些超复杂密码的网站都会被拒绝。

ASP.NET成员资格会为您执行大部分围绕安全性的努力工作,只要它的设置正确即可。

然而,有一些事情ASP.NET成员不能为你做什么,如:

  • 确保使用HTTPS
  • 防止CSRF及类似袭击
  • 确保所有的web请求路由到ASP.NET防止静态内容被IIS提供并绕过ASP.NET身份验证
  • 检查用户是否为人(CAPTCHA)

更多关于安全的最佳做法我想看看OWASP

1

似乎有你可能要担心至少三次攻击:

  • 在一个特定的用户有针对性的攻击。对于攻击者而言,您想让的登录更困难,但不会太困难。验证码已足够(但如果用户未在登录页面上显示,则不要再次输入密码)。
  • 对许多用户的大规模攻击。锁定个人用户有点毫无意义,因为攻击者可以尝试(说)3个密码,然后转到其他帐户。每IP的CAPTCHA可能就足够了,但您可能还想对每个IP进行速率限制(或者对于列入白名单的代理的X-Forwarded-For)。这取决于攻击者的僵尸网络的大小;一个足够大的僵尸网络可以在多个僵尸网络/站点上分发攻击,以便每个站点从每个IP获得较低的速率。
  • 密码数据库的脱机攻击。在这种情况下,即使使用一个好的散列,你也需要至少大约50比特的熵(NTLM使用MD4的单个呼叫,这个呼叫是而不是,这是一个很好的散列),你无法获得相对正常的8个字符的密码(8日只有52.4)。

您可以将每次尝试IP存储到树中,在树中将树的密集部分分组在一起。然后将它分开(每隔10分钟构建一棵新树,将老树保持10分钟左右)。这可能是错误的假设,即相邻的IP可能会表现出类似的行为,但是会优雅地将其降级​​为(比如说)/ 24。

如果您感觉特别慷慨,您可以在登录时存储单独的cookie,并且在注销时不会清除,并将副本保存到数据库中(128位随机值应该足够好)。在登录尝试中,如果浏览器显示正确的cookie(例如,允许对cookie进行3次尝试而不计算每IP或每个用户的失败率),则对浏览器“更好”。这意味着即使用户帐号被强制使用,用于访问帐号的最后一台机器也不会显示验证码。

一般来说,谈论密码熵比密码长度和“字符类型”更有用—我敢肯定,几乎每个人都只是制作第一个字母大写,并在结尾处贴一个1。我还没有看到任何“人性化”的密码生成器,它们也声明密码熵。