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
