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

Reply via email to