Hi Doug, Is there a timescale for rolling back / making the change to the new scheme?
We're just putting the finishing touches to moving to OAuth and we're experiencing the issue when using verify_credentials to get the users basic details once we've got the token back from the authentication process. We're experiencing the issue when: 1. Testing our login and authentication processes 2. When users login and logout of our application frequently A heads up on when these changes will be made would be useful. Thanks, Bob On Jul 29, 6:37 pm, Grant Emsley <[email protected]> wrote: > Locked out of authenticated resources for that account, or will that > IP not be able to login to any account? > > On Jul 29, 1:14 pm, Doug Williams <[email protected]> wrote: > > > Ray,For clarity, we will roll back the current restriction of 15 calls per > > user per hour to account/verify_credentials, and implement the proposed > > scheme: > > > > ... 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. > > > Thanks, > > Doug > > > On Wed, Jul 29, 2009 at 9:51 AM, Ray <[email protected]> wrote: > > > > Doug, > > > > I'm in a similar situation as that voiced by TinBlue. This change has > > > affected our iPhone App. We also want to encourage you to rollback > > > this change ASAP. > > > > When you say "This approach is what we are going to take.", do you > > > mean rolling back the fix so as not to affect multiple, successful, > > > authorized logins? I'm hopeful that "this approach" means that our > > > apps will not be affected yet again by changing to a new auth > > > approach. > > > > I appreciate you all keeping this thread informed. > > > > Ray > > > > On Jul 27, 11:23 am, Doug Williams <[email protected]> wrote: > > > > Thanks to everyone who has contributed feedback. This approach is what > > > > we > > > > are going to take. > > > > Alex will be making this change shortly. I will update this thread when > > > > there is timeframe to share. > > > > > Thanks, > > > > Doug > > > > > On Mon, Jul 27, 2009 at 7:52 AM, TinBlue <[email protected]> wrote: > > > > > > What is happening? > > > > > > This rollback is taking far too long for something that has affected a > > > > > lot of people! > > > > > > On Jul 25, 2:32 pm, Dewald Pretorius <[email protected]> wrote: > > > > > > Doug, > > > > > > > I would prefer to adopt OAuth instead of writing code for Basic > > > > > > Auth. > > > > > > > So, you guys need to move OAuth out of public beta into full > > > > > > production sooner rather than later. :-) > > > > > > > I manage 100,000+ Twitter accounts, and I simply cannot take on the > > > > > > support workload of answering user tickets when there's a snag with > > > > > > OAuth beta. > > > > > > > I monitor these forums and the API Issues and still see too many > > > OAuth > > > > > > issues being reported to give me a level of comfort that I can > > > > > > safely > > > > > > switch over to OAuth. > > > > > > > On Jul 24, 5:46 pm, Doug Williams <[email protected]> wrote: > > > > > > > > Well said Joshua. > > > > > > > > Dewald, you have identified the risk of using basic > > > > > > > authentication. > > > If > > > > > > > your users being locked out due to malicious behavior, you should > > > > > > > either implement further user-level rate limiting on your side or > > > > > > > adopt OAuth. > > > > > > > > Are there any other glaring omissions in our thinking or should we > > > > > > > proceed with this as our solution? > > > > > > > > Thanks, > > > > > > > Doug > > > > > > > > On Fri, Jul 24, 2009 at 11:08 AM, Joshua Perry<[email protected]> > > > wrote: > > > > > > > > > Jim's concern is valid, fortunately OAuth is immune to > > > brute-force > > > > > attacks > > > > > > > > once the access key has been issued to an application. For this > > > > > reason alone > > > > > > > > I would urge people to switch to OAuth if at all possible. I > > > would > > > > > hope > > > > > > > > (and assume) that if login attempts for an account are locked > > > > > > > > out > > > > > that a > > > > > > > > user would still be able to successfully use an already > > > authorized > > > > > OAuth > > > > > > > > driven application. > > > > > > > > > Unfortunately allowing a successful un/pw login while an account > > > is > > > > > locked > > > > > > > > out even when the correct password is presented effectively > > > bypasses > > > > > the > > > > > > > > whole reason for a lockout in the first place, preventing > > > brute-force > > > > > > > > password attempts. If an attacker used a dictionary or > > > brute-force > > > > > attack > > > > > > > > and the account was locked out after 15 attempts, then they > > > > > > > > could > > > > > continue > > > > > > > > trying even though the system replied "locked out"; if they > > > > > eventually sent > > > > > > > > the correct password it would just bypass the lockout and they > > > would > > > > > then > > > > > > > > know the correct password. > > > > > > > > > Perhaps Twitter could implement a selective captcha, I know they > > > are > > > > > > > > annoying but if executed properly it could be effective > > > protection > > > > > against > > > > > > > > brute-force and dictionary attacks. Say after 3 or 4 failed > > > attempts > > > > > without > > > > > > > > a captch the API would then include a captcha image URL in it's > > > > > response > > > > > > > > that the application would then need to show to the person and > > > > > include the > > > > > > > > user's response with the next authentication attempt as a header > > > or > > > > > POST > > > > > > > > variable. The site stackoverflow.com does this to great effect, > > > if > > > > > you > > > > > > > > create posts quicker than a certain threshold which a person > > > would > > > > > not > > > > > > > > exceed then they pop a captcha up, in the normal use of the site > > > you > > > > > will > > > > > > > > never see one; I've only hit two captchas in the last in the > > > > > > > > last > > > 8 > > > > > months > > > > > > > > using the site. > > > > > > > > > Josh > > > > > > > > > Dewald Pretorius wrote: > > > > > > > > >> 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" <[email protected]> > > > 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 > > ... > > read more »
