tags:

views:

389

answers:

4

Hi, I have designed login page for one of our website where i have used following resources

  1. Login Name and Passowrd lable and textboxes
  2. Combo box for multilingual support
  3. Submit button.

Now to make this page more secure i am planning to use following extra points.

  1. CAPTCHA/ RE-CAPTCHA
  2. Number of Retry: block after 3 unsuccessfull login attempt.

I have seen these extra things by visiting other sites. I would like to know

  1. whether these extar point makes somediffrence for security?
  2. How should we implement number of retry? When should we again unblock user account.

What is right approach?

Please help

+3  A: 

You could use ASP.NET's login control and the default SQL membership provider. If you do this, implementing the number of retries before a user is locked out is as easy as setting a config value.

Take a look at MSDN here, and scroll down to "Using the SQLMemberShipProvider" section.

Esteban Araya
+1  A: 
  1. If you are updating an existing site that has had security issues, captcha can't hurt. If it is a new site, is it public or for internal use? You can always add this later if you run into issues. If there are sensitive materials, you'll get more mileage out of enforcing strong passwords from users (though this can be annoying to them) than you'll get out of captcha (also annoying).
  2. Several options here. You can record IP address on each attempted login and record failed attempts. 3rd fail from same IP inside of 15 minutes blocks further attempts (every attempt fails with locked account message). Additional attempts reset the 15-minute "timer." Really, there is no timer, but with each attempted login, the log it checked to see whether it has been locked within the last 15 minutes.

The login attempt log can be stored in many ways -- often a database table. There may be value in keeping a record of every login (in case there is ever a breach), or maybe you only want failed logins. Optionally, you could remove failed logins from the log when the user successfully logs in. You could have a database routine that cleans up the table from time to time of failed login records that have exceeded the waiting period (15 minutes, or whatever).

Obviously, 15 minutes is arbitrary -- this can be 1 minute or 24 hours or until the user calls your customer support line to get it reset.

Jay
Well, okay, I'm voting for Esteban's answer.
Jay
I'd said the same thing, but you'd hate for the guy to implement the entire thing when it's already been done for him, right? :)
Esteban Araya
Thanks,Now suppose user try 3 time wrong credential, then what message should we shown to user?Whether i should say, try after 15 minutes or say general message?
Hemant Kothiyal
Be careful with the IP restriction: if there is a proxy server between you and the user, you might get the IP from that proxy and block everyone that is behind that proxy.
Hans Kesting
Deciding on what to show after the failed attempts is important. I'd say do NOT indicate the 15 minute waiting period. If anyone is seriously trying to hack your site, they're doing it programmatically. Don't help the algorithm by telling them what delay to put in between attempts.Beyond that, it depends on what the site is for, and what resources are available to the user to authenticate (can they call or request a new password, or password reminder)?
Jay
+1  A: 

Look at the NoBot control from the AjaxControlToolkit (http://www.asp.net/AJAX/AjaxControlToolkit/Samples/NoBot/NoBot.aspx). That provides some "bot protection" without the user needing to decipher a captcha.

Hans Kesting
+1  A: 
  1. General - Require a strong password and limit the login tries/user (not IP/cookie). If you add a five minute lock-down for a user name after three fails a bruit force attack would take more years than you site will live (dictionary attacks are not possible since you require strong passwords)*.

  2. Protect your users - In your form, don't post the password in clear text, post a hashed version eg. md5([your domain] + [password]) The reason you add your domain is to protect the hash of the password from the server owner (you), so if your user DB get hacked the hashed passwords you stored are useless even if your users use the same password on multiple sites. If you like stronger hash you could look for some SHA version. Make a js script that replaces the password with the hashed one before sending. Remember to have this hash calculated on the registration page, never let the password be sent from the browser in clear text. You don't want to know it!

  3. http://en.wikipedia.org/wiki/Cross-site_request_forgery, also have your server sign the cookie values to make cookie forgery harder.

  4. Encryption - Either use TSL/SSL or get a RSA script and encrypt your form data with your severs public_key.

  5. Man-in-the-middle - The hardest threat to guard against, I guess that https is the easiest way but a trusted certificate costs money. If you self sign users today don't bather to look if it's the right cert or not, this requires too much form the users. Buy a cert or hope you don't have a man-in-the-middle.

I would never use re-captcha for login since a lock-down of user name is more effective and less disturbing for a user. Though re-captcha is good for account registration so you don't end up having a lot of scripted accounts.

  • Limiting login tries/username could be used to block a user to log in. Bruit force attacks are still available since they can attack a lot of usernames and not only one, thus keeping the attack under the limit/username block. But for a site with few (less than 10.000?) user accounts you should be quite safe.
MyGGaN
How can we handle case, where any hacker open multiple session of browser and supplied same valid account credential.Is not CAPTCHA require in that case?
Hemant Kothiyal
I don't really get the case. If a user with valid credentials (why call him hackar?) log in from multiple sites/browsers, what's the problem you want to solve? Are you trying to limit so you only have one valid session/account? Or are you afraid of DoS attacks?
MyGGaN