The rollback should be deployed tomorrow. Sorry for the delay. On Sat, Aug 1, 2009 at 23:36, Jesse Stay<[email protected]> wrote: > A timeframe would be very helpful. This is turning out to be a headache as > I'm testing. If my own user is having to log in over and over to test my > app, I'm quickly hitting the verify_credentials limit (and I'm even using > OAuth). I'm getting really frustrated. > Jesse > > On Fri, Jul 31, 2009 at 8:01 PM, Bob Thomson <[email protected]> > wrote: >> >> 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 » > >
-- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
