A twitter bug realted to IP Addressing and Authentication.

Question

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

Answer 1

From the description provided in the question, Twitter seems to have its lock-out logic tied to:

• IP Address, or possibly part thereof, for example its class C (the first 3 bytes of IP Address.
• A [relatively high] number of failed attempts

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.

Answer 2

While this is one possible scenario to break into an account. There are other profitable routes including starting with a list of commonly used passwords and trying to find users who have these passwords with the advantage that attack is spread across users.

Most login systems use a combination of features all/most of which are of course known to abusers. Some techniques include using failed login attempts by username, by password even if against different users, age of cookie, the diversity of cookie, IP address, and some detection of whether SOCKS or other proxies are being used. Some even try to use some form of user or device fingerprinting that raise the bar for abusers. Detection is followed by slowing down attempts by using CAPTCHA or temporary locking.

Of course it may be really bad idea to lock IP because a single abuser behind a NAT device can cause denial of service to all other users behind the NAT. Also I believe a few countries in the middle east proxy even SSL traffic, so blocking an IP could block all users - this may not be a concern for you.

google and other sites also have deal with attacks conducted in parallel across servers that are geographically distributed.