To be honest ever since the x-rate-limit HTTP headers were added we removed the call to verify_credentials from our Twitter API layer.
Every time that our Twitter API layer does an HTTP request it squirrels away the header values and any requests to our API from the application for rate-limit information is just fulfilled from those saved variables. So we don't need verify_credentials for rate-limit information Every time that our API does an HTTP request it watches for unauthorized HTTP responses, so we don't need verify_credentials to verify that our app is still authorized on the account or that the user's password is still the same. Every single twitter API method could be used to brute-force by sending HTTP auth headers and watching the HTTP response, but you are rate-limited to 150 requests/hour/ip, if this rate-limit is good enough for all the other attack vectors it should probably be good enough for verify_credentials. In fact verify_credentials is basically a nop function, which IMHO really isn't needed any longer. Josh On Jul 21, 7:00 pm, Doug Williams <[email protected]> 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
