I am building a web application where i got trapped in login module. I was about to implement lock out functionality using IP address of machine but for Dynamic IP router can be restarted so I was thinking to store MAC address which was not feasible to retrieve on web. Then i tried to know functionality on GMAIL and Twitter
Cases that i checked
I want to lock a user from that system where he attempts to login more than 20 times continously, that user must be able to login if he tries to login from another system.
Now i was trying this kind of functionality on twitter that how they implemented it.
When i tried to login to my twitter account from my mozilla browser around 18-20 times i got locked out for 60 minutes. Now i tried to check whether this locking is browser dependent or server dependent. So i tried to login from IE and in very 1st attempt i was shown locked.
Then I tried to login from another system i.e. another (IP address) then i got access to my account. From this i concluded that it might be checking IP address.
Then I finally get back to my PC and tried to login from Tweet Deck i.e. third party software then i got access, then again i tried to login from browser then it still showed me as locked for 60 min.
IS TWEET DECK ACTING AS A PROXY ?
WHAT IS GOING ON BEHIND THE SCENE, IS
IT CHECKING MAC Address, IP ADDRESS OR
WHAT ? IS IT STORING INFO ON DATABASE
From the description provided in the question, Twitter seems to have its lock-out logic tied to:
I doubt that anyone uses the MAC Address as this is relatively difficult/impossible to get to, and offers relatively few advantages over IP address “identification” (both IPs and MAC can be spoofed anyway…)
The reason Twitter uses IP addresses, to probably in an attempt to keep hackers at bay, while not inconveniencing at all the legitimate users. The idea it to prevent Denial Of Service, allowing someone to prevent a legitimate user of Twitter to use the service, simply by failing to login under this account multiple time (i.e. the goal being to disable to the account not to guess its password).
The problem with this approach, however, is that it gives the “bad guys” more chances to eventually get in; to alleviate this risk, the login logic may also include a count of how many different IP addresses are currently locked-out for a given account, allowing it to completely disable the account when this count reaches a threshold: “Man, five different IP addresses have attempted multiple times to get to this account… Let’s lock it out, and email the owner!”.
The type of login logic you should implement for your web application depends very much on the nature of the site, the number of users, etc.
There’s nothing wrong in emulating what the tier 1 sites like Google and Twitter are doing, but your individual situation may provide alternative opportunities or requirements.
For example having much fewer logins per second, you may implement a fancier set of rules (say rules which match current IP with IP addresses formerly/recently used for the account and be more tolerant in these cases). Another example: if you customers are paying for the service and/or if their privacy is seen at a premium it may be preferable to err on the side of caution, i.e. to [sometimes] lock-out legitimate users rather than allowing [potentially] hackers.