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 <> 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<> 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 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" <> wrote:
> >>> My concern with this proposal is that it opens up denials of service,
> >>> not to, 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 <> 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 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.
> >>>> 2.
> >>>>      Regards,
> >>>> Doug

Reply via email to