Seems fine. Is there a timescale for rolling this out?
On Jul 24, 9:46 pm, Doug Williams <d...@twitter.com> 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<j...@6bit.com> 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" <james.ren...@gmail.com> 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 denied ID. > > >>> Comments expected and welcome. > > >>> Jim Renkel > > >>> On Jul 21, 6: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
