Jim raised a huge weakness with the authentication rate limiting that could essentially break third-party apps.
Anybody can try to add anybody else's Twitter account to a third-party app using an invalid password. If they do that 15 times with a Twitter account, the real owner of that Twitter account, who may have added his account a long time ago with the correct password, is locked out from using that app for an hour. I believe you will absolutely have to reset / remove the lock as soon as the Twitter account uses the correct password. On Jul 22, 4:58 pm, "jim.renkel" <james.ren...@gmail.com> wrote: > My concern with this proposal is that it opens up denials of service, > not to twitter.com, but to "associated" sites such as twitpic, or my > site twxlate, among others > > For example, Lance Armstrong is a heavy user of twitpic. It is very > easy for anyone to find Lance's twitter ID (@lancearmstrong), view his > status updates, and see that he is a frequent user of twitpic. Now, > someone that is "unhappy" with Lance, say one of George Hincapie's > ardent fans that really believes that Lance was a significant > contributor to George not winning the maillot jeune last Sunday, > could go to twitpic, fail to login as Lance the requisite number of > times, and deny Lance access to twitpic. > > Not only celebrities would or could be subject to such denials of > service. I notice that @dougw occasionally uses twitpic! :-) > > One solution to this problem is to add to each twitter account another > "private" ID. By default this private ID would be equal to the > existing (public) ID (If not equal to the account's public ID, it > would have to be unique among all twitter IDs, both public and > private.). > > The public ID would be used just as the existing twitter ID is now: > others would use it to follow, mention, DM, etc., the user. > > But the user MUST use their private ID for authenticated requests > through the API, and CAN also use it for non-authenticated requests. > In either case, twitter would treat a request from a private ID as if > it came from the corresponding public ID. > > Blocking the public ID because of excessive authentication failures > would NOT block the associated private ID unless they were equal. > Changing your public ID would also change your private ID if the two > were the same before the change, i.e., they would remain the same > after the change. > > It may seem onerous to require all users to also have a private ID, > but since it defaults to be the same as their public ID, only those > concerned about their service being denied would change it and > subsequently use it instead of their public ID to access associated > sites such as twitpic or twxlate. > > In fact, I think this change, though potentially large on the twitter > side, could be implemented without any changes to users or associated > sites, with one small, obscure exception: now, if I attempt to create > a new twitter account or change the ID of an existing account, and > find that the ID I want is in use, I can view that account; if this > were implemented and I attempted to use a private ID that was not the > same as its associated public ID, I could not view the account using > the denied ID. > > Comments expected and welcome. > > Jim Renkel > > On Jul 21, 6:00 pm, Doug Williams <d...@twitter.com> wrote: > > > Devs --A change shipped last week that limited the number of times a user > > could access the account/verify_credentials method [1] in a given hour. This > > change proved hasty and short-sighted as pointed out by the subsequent > > discussion [2]. We apologize to any developer that was adversely > > affected. Given the problems, we want to fix this in a > > public and transparent manner. > > Like most web services, we limit the number of attempts users can make to > > login to > > their accounts on Twitter.com to prevent brute force dictionary > > attacks. This same security is not extended to the platform > > and leaves accounts vulnerable to the same method of attack through the API. > > > The change we shipped to limit user accounts to 15 calls an hour to the > > account/verify_credentials method [1] was intended to mitigate this risk. It > > was thought to limit the number of tests a potential attack could run in the > > hour, even in a distributed fashion. However, we only protected a single > > resource which still leaves all other authenticated methods exposed as a > > vector of attack (limited only by the API rate limit). > > > Our thinking is now that we will limit the total number of unsuccessful > > attempts to access authenticated resources to 15 an hour per user per IP > > address. If a single IP address makes 15 attempts to access a protected > > resource unsuccessfully for a given user (as indicated by an HTTP 401), then > > the user will be locked out of authenticated resources from that IP address > > for 1 hour. > > > This scheme has all of the positive effects that we need, however we want to > > make sure that we have thought through all of the potential problems on the > > developer's side before we proceed with this change. Please contribute to > > the subsequent discussion if you have an opinion or concern. Once we come to > > an agreement, we will update with details and a timeline for shipping this > > update. > > > 1.http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-account%C2%A0ve... > > 2.http://groups.google.com/group/twitter-development-talk/browse_thread... > > > Regards, > > Doug
