Vijay Krishna's Notes http://vijaykrishna.posterous.com Most of my notes as a student of computer software and everything around it. posterous.com Sun, 06 Feb 2011 13:08:05 -0800 Login Issues http://vijaykrishna.posterous.com/login-issues http://vijaykrishna.posterous.com/login-issues The other day at office, there was some general talk on how people get some really retarded ideas when it comes to making a login process really secure. The particular feature that was in focus concerned the idea of temporarily deactivating a person's login after 3 unsuccessful tries. The simple issue with this method is thus: any one, can deactivate your account if he knows your user-id by making 3 unsuccessful log in attempts using incorrect passwords. This can make life hell for you. So, what are the possible work-arounds? Well, take a look at the core issue that you are trying to address by deactivating accounts after 3 unsuccessful login attempts. I think the core issue is to make it difficult for the person/bot who is trying to login, in case of 3 unsuccessful attempts. Now, try and understand this: the person or bot may not be the actual user himself. So the locality of the issue and its solution should be at the client side of the application where the login attempts are being made, not at the data level where the respective user information is being stored. In a nutshell, make it difficult for the person who is logging in by creating trouble at the UI not by completely deactivating the account itself from the DB. What are the ways to create hell at the UI? There are plenty of them. Off hand i can think of using a captcha after 3 unsuccessful attempts. See, now the entity logging in or trying to log in using a brute force attack will find it difficult to log in. Thus, you are not really creating the issue for the account holder. So, the next question in the pipeline is, how would you create more trouble? Here are a few suggestions: a) Disable the use of the keyboard while entering the credentials. Present the user with the virtual keyboard while entering the userid, password and the captcha. Why I say captcha is that you can use this method after 3 or 5 unsuccessful attempts after the captcha is initiated. This will force the use of the mouse making life miserable for the cracker, trying to crack into some account. b) Start using an audio captcha after a while. But, with this you are negating the users who might be deaf. But that is your call. c) Start asking all kinds of user related information such as the Date of Birth of the User, the Secret Question, etc. d) If all this does not work, send an Authentication code to his email id with which he has registered into the system. If none exists, then ask for a temporary one for the same, and keep asking for the email id on every failed login. This way you can actually keep a track of the kind of email ids being used and you can actually do some background check on the user himself. Mind you all these are ideas that have just bounced off my head. I am sure you can come up with more creative solutions for the same issue. Ofcourse, i would like it if the people, building software systems involving logins for my critical systems such as banks and may be online voting in the future, were not to use such methods. Deactivate the accounts or login credentials. Do so especially in the case of ATMs. That is why i guess we use them in the first place. ;)

Permalink | Leave a comment  »

]]>
http://files.posterous.com/user_profile_pics/1369599/pic.jpeg http://posterous.com/users/hcGXxsTkwP6SS Vijay Krishna Palepu vpalepu Vijay Krishna Palepu