Josh, is there a way, without verify_credentials, to identify that users have changed their Twitter passwords (and therefore you are no longer able to authenticate for them)? For client apps, I don't see this being as much of a problem, but for server-based apps that run regular scripts on behalf of users this could become a regular issue, which is why we were running it. In addition, what is the best way with OAuth to identify the screen name of an individual? verify_credentials is the only way I'm aware of, unless there's something I'm missing (which is probably very likely). I'd love to know if there's a better way. A best practices doc on how to retrieve user information, and how to best verify users have not changed their passwords would certainly be useful I think. I'd like to know how Twitter recommends we do this.
Jesse On Tue, Jul 21, 2009 at 8:50 PM, Josh Perry <[email protected]> wrote: > > 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
