Intellipass - A behavior based password lockout mechanism
I am pleased to announce Intellipass (a behavior based password lockout mechanism). Most of the password lockout mechanism today are static, which means, they lock a user out after a certain number of incorrect password attempts. This feature is implemented to prevent brute force attempts against the login functionality. Even though this feature does what it’s supposed to, it has its own shortcomings too.
From a security point of view, this feature can be abused by a bad guy to lock most or all of the users by writing a script with all the possible permutations and combinations for a username (which are mostly alphabets, if not alphanumerical), resulting in a denial of service.
From usability point of view, there is always a debate as to the number of attempts to be allowed before locking a user account. Most websites allow 3 attempts while some (very few) allow 5 or sometimes 7. What is the right number for this feature is a subject of debate or at least a different blog post. However, It is a big inconvenience for the user if he is locked out.
Till now, there is no other option but to implement a static password lockout mechanism, which has become a de-facto standard for almost every website. Intellipass tries to bridge the gap between the security and the usability aspect of this feature. By storing every login attempt of a user, Intellipass can intelligently understand user’s past behavior and act accordingly. For ex. If a user locks himself out every time, then Intellipass will dynamically increase the number of attempts from 3 to 5 or from 5 to 7. On the other hand, if a user logs in first or second time every time he or she tried to login in the past, but for some reason has taken 3 attempts this time, Intellipass will automatically reduce the number of attempts from 7 to 5 or 5 to 3. The second component of Intellipass is throwing in a random captcha or insert a time delay between the login attempts to prevent automated attacks.
Initial release will be in JAVA. We are requesting for everyone to send in their suggestions and ideas as to what can be done to make Intellipass usable by various companies. More details on Intellipass can be found here.
4 comments:
Hi there, thanks for your post.
I've read the specs doc, but i can't find any mention of what constitutes a 'user'. Would it be a given submitted username? The user's source IP address? A unique cookie assigned to the user's HTTP session? A combination of the above?
I'm asking this because the logic used by your software to build a unique identity could have an impact on whether or not the lockout mechanism can be bypassed.
A classic example is an app that limits the number of invalid passwords *per username*. The attacker can often get over this logic by trying a very simple/common password - e.g. the weakest one that would comply with the password complexity requirements - and simply try that one password against a huge list of usernames. This is what I like to call 'reverse password cracking'. In a sense, the attacker is not cracking passwords, but usernames instead.
Would your software prevent this type of attack? i.e.: try a given password against many usernames, as opposed to many passwords for a given username
It's amazing how many apps I've seen vulnerable to this logic flaw, including financial ones.
Hi ap - I know a lot of websites are vulnerable to that kind of DoS attack. This release of Intellipass won't prevent against the reverse password cracking, at least not in the current version. Maybe this kind of feature can be added later on.
Currently it will take the username and also account for the ip address too.
Good Idea Anurag and thanks for the post.
is it possible to dynamically increase the password tryouts when incorrect password is close to correct password.
Some times user will try to press another key instead of correct key or forget the case sensitivity . exmaple :
if the original password is helLo ,and user tries hello , HeLlo, heLlo for 3times... since those wrong passwords close to the original password we can dynamically increase tries from 3 to 5 like that ..
don't know whether my idea works or it will violate security policy, correct me if I am wrong.
Hi Jithendra - The challenge with this approach is that it could be a legitimate user or an automated script. It's hard to find that automatically.
Post a Comment