views:

85

answers:

4

I just read an article saying that passwords with 7 characters are no longer safe. However, if the server increases the time to retry a login attempt after each login attempt, then brute force attacks are useless. How do you create such logic in asp.net? Somehow I guess the server side code needs to remember the ip-address that tried to login and should increase the response time with each new try?

+2  A: 

IP address isn't really a secure method of identifying the user. You could try storing the last time a login attempt was submitted in a cookie, but if the browser doesn't accept them, it'll be of limited use. Session variables also require cookies, so they're out.

Some sites (yahoo comes to mind) start showing a Captcha form after the third or so attempt. You have to correctly answer the captcha in addition to your login details.

Another option would be to disable an account after X failed attempts (which can be tracked in your database), but I personally dislike this as it tends to force me to call someone to get my password reset whenever I forget one.

David Lively
Mmm, how should I put this. Imagine that somebody tries to login withoug using the login page, but some code trying to login each time. Then I guess, server side, you would need to remember that next time a Captcha is needed. Hard to explain my question.
Lieven Cardoen
If you are are concerned about brute force attacks, you could display the CAPTCHA every time. But locking an account out after too many attempts in a given window is perfectly adequate for most sites. If you require higher security than your average website, there's a lot more to it than blocking brute force attacks on passwords. Look at OWASP - there's a ton of other types of attacks out there like CSRF and XSS that are serious threats to every web application.
saille
@David - you don't necessarily have to contact someone when you account is locked out. How about a system that sends you a link to unlock your account via an email?
saille
A (decent) CAPTCHA per-ip or per-account is decent. However, rate-limiting per IP is also okay, provided you assume that not too many people use proxies, and that you assume there aren't so many botnets out there that *any* form of rate-limiting is useless (because if I was a botnet, I'd just try lots of accounts with a "few" common passwords).
tc.
+1  A: 

Many brute force attacks occur offline. That's why failed-attempt lock-outs are no substitute for requiring complex passwords, using proper "salt", and key-strengthening.

erickson
Maybe a stupid question: But how should anyone crack my ASP.NET App offline? To the answer, ASP.NET Authentication looks your account after too many failed attempts. Could be a solution too, no? Assuming no offline cracking :-)
Remy
Suppose an employee takes a tape with a backup of the user database.
erickson
+3  A: 

ASP.NET has a built-in mechanism to prevent brute force attacks against login passwords. Refer to the maxInvalidPasswordAttempts Membership property.

IMHO 7 character passwords are perfectly adequate for most web applications (my bank allows 7 char passwords) provided security best practices are followed, such as securely hashing passwords and blocking brute force attacks.

Once you get beyond 7 or 8 character passwords, you are really saying "my app needs to be super secure", in which case you ought to consider individual client SSL certificates. Requiring more characters in a password has diminishing returns. How many of your users can remember complex 8 or 9 character passwords? They end up writing them down. Personally, I get turned away by any site that requires me to create some super-complex password.

ASP.NET Membership does most of the hard work around security for you, as long as it is setup properly.

However, there are some things ASP.NET Membership cannot do for you, such as:

  • Ensuring HTTPS is used
  • Preventing CSRF and similar attacks
  • Ensuring all web requests are routed to ASP.NET to prevent static content being served up by IIS and bypassing ASP.NET authentication
  • Checking that the user is a human (CAPTCHA)

For more on security best practices I'd look at OWASP

saille
+1  A: 
tc.