I've been updating my site to use OAuth and have found this to be a big problem. Without the ability to call verify_credentials I haven’t found a reliable way to ensure that logged in users with a valid session are still authorised with Twitter. It's unlikely they will revoke access in the middle of using the site, but the potential is there for an action to fail because of this. With verify_credentials I am able to check their OAuth tokens are still valid and also make sure their profile info is up to date. Spent several hours having a headache over this, especially since the API says these calls are unlimited. I was looking all over for unescaped loops and all sorts :)
Agree that either making OAuth calls unlimited (since there shouldn't be a security vulnerability there) or making valid calls unlimited (same reason) whilst limiting invalid calls makes the most sense. As you say, you're still getting the security you want but without penalising legitimate users. If this is going to be a quick fix/ rollback, I'll go back to using the method and deal with the low limit when testing for this week. Stuart On Jul 22, 6:49 am, Jesse Stay <jesses...@gmail.com> wrote: > 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 <j...@6bit.com> 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 <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
