I think Dewald's concern is very valid - and even though OAuth might solve it, the reality is that most (if not all) desktop and mobile apps are using Basic Auth today for various reasons, so if you implement this policy as described, there's a pretty high risk that many users can be locked out of twitter from their usual ways to access it.
Also, again a reminder that AFAIK the last official status re: OAuth from Twitter was that it is still in beta, and therefore not recommended for production use - or has there been another announcement that I missed? Marco 2009/7/24 Doug Williams <d...@twitter.com> > > 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 > >>>> > > > > >
