You didn’t expect me to have only nice things to say, did you? There are a couple of things I have to question.

It’s only a draft

Despite this spec being a draft, Facebook (who are represented in the working group) have gone ahead and implemented it anyway. Although this is a step up from the non-standard methods they’ve employed to date, it does make me wonder. Will the spec be finalised according to their implementation? Will they change their implementation if the spec changes? Or will they end up going in separate directions? (think ECMAScript 4/ActionScript). As with my gripes about the Open Graph, how “open” are standards when we have self-interested corporations in the driving seat.

Looser security for JavaScript clients

The so-called “user_agent” journey serves the needs of front-end applications that don’t have access to a web server. (i.e. JavaScript only apps). This support comes at a cost to security because request signing is not required. (More to the point, signing would be redundant). The risk is a limited one – the “bearer tokens” must only be sent over SSL, so the worst you can do is take control of an app under the authentication of your own account. Still, I imagine it would be possible to post content that the app did not intend. (use your imagination!) My main gripe here is in justifying the trade off. The loosening of security is in favour of making apps easier to implement for more people – i.e. a Facebook business interest. I don’t think that’s a good enough reason to weaken the specification.

If you’re impatient, you may wish to skip to the good bit.

Preamble

Now, how did this app manage such spread when there are so many like it? Possibly because it tweets from your account when your results are ready. This is not uncommon and it can be a nice feature that I might recommend. With the difference that it should be a 100% opt-in feature. TweetCloud’s start button says “make and tweet cloud“, so it does warn you. But people don’t read – they click.

TweetCloud insists that you log in before you can use it. It uses OAuth for this which is good (+1 point). Doing this means it can make calls to the Twitter API within your hourly request limit, rather than exhaust its own. (useful if you’re not whitelisted). But the real reason you must authenticate with TweetCloud is so that it can update your status. When building an app you have to seriously justify asking the user to authenticate/register etc.. As a general rule, the user should see that this action is for their benefit, not yours.

Good examples of this done right would be:

• TwitPic, which has a genuine use for tweeting on your behalf.
• Canabalt, a game where you want to share your score for social kudos.

Both of these apps make the tweet opt-in each time.

The good bit

While TweetCloud was busy generating the cloud (which took a minute or so) I dived off to my Twitter settings and revoked the permission I had granted the app. If you don’t know how to do this, it’s under “settings > connections”, or here: http://twitter.com/account/connections

As soon as you revoke this permission the app can no longer use the access key that it has obtained. It needs this for any API call that must be authenticated. e.g. getting your public timeline of tweets does not require authentication, whereas updating your status does.

Interestingly the cloud generation continued to churn away. This suggests that the app was actually paging through my timeline without even using authentication. i.e. making public API calls under its own rate limit.

Lo and behold, upon completion there was no tweet from my account.

I also decided to post my cloud as a TwitPic, just to say … well, you know.  TwitPic doesn’t use OAuth, which it should, but that’s another post.

A few other things to note about “connections”:

• When you grant access to an app, it can store its access key forever. i.e. Twitter don’t provide a key expiry feature like Facebook do. So you should revoke permissions from any app that you’ve stopped using.
• My statistics from TwitBlock suggest that about 1% of people actually do this. (about 400 of 30,000 users have revoked my key)
• Signing out of Twitter does not prevent the app using this access. An app with an access key can tweet from your account whenever it wants until you revoke
• The read/write permission you can see is set by the app, not by you. Twitter doesn’t offer granular permissions like Facebook do

1. A brief back-and-forth on Twitter with @kaigani where I outlandishly claimed that Facebook Connect is a phishing scam waiting to happen
2. The warning of another Twitter scam that typically exploits the layman’s inability to spot a fake URL.

Facebook and Twitter both offer authentication services arguably known as “single sign-on”. Facebook Connect is a proprietary system, and Twitter offers a system based on the OAuth standard. These services do something quite marvellous – They allow you to authenticate with a another website without the third party ever seeing your password. What’s makes it even more handy is that you’re probably already signed in to these popular services, so you may not need to enter your password at all. The problem is when you do.

If the mother service decides you aren’t logged in, it will have to present you with a username/password prompt just as if you were entering the main site. Here’s an example Facebook Connect popup:

A complacent user is likely to fill in these credentials without checking whether this page belongs to Facebook. This is the classic Phishing model, and I would argue that it is made worse by the additional trust the user may place in this familiar system. Furthermore, some implementations present this dialogue in a overlay form where no address bar appears at all.

There are various lines of defence available to the user at this point, and they are all in the browser.

1. The URL
Most phishing scams use cleverly manipulated URLs that can easily trick an untrained eye. The fact is that the address bar and the URL are (from an end-user perspective) quite technical aspects of using the Internet. These “connect” dialogues are prone to this problem, and to make it easier for the phishing gangs they don’t have to recreate the whole home page,  just one small window. Even for Internet professionals, an accurately copied design may provide little reason to glance at the address bar.

2. The SSL Certificate
In the unlikely event that hackers have infiltrated your ISP, you still have the server certificate to ensure the site is legit. Observant readers will notice that the above image does not show a secure page. This is a failing of the vendor and of Facebook. A secure page does exist for Facebook Connect [see below] but Facebook should not offer standard HTTP at all and in this example the vendor should have used the SSL version.

Twitter also fails to restrict their authentication screen exclusively to SSL. To make matters worse their SSL screen does not contain full identity information (see below). Many Twitter apps don’t use the SSL page, and in fact the application settings page for developers lists the OAuth service URLs as HTTP variants only.

Is this a technology problem, or a human problem?

These scams exploit ignorance and complacency – Two things that user-friendly web services like these can only perpetuate. All the cryptography magic and clever security models behind these services can’t actually prevent phishing scams, and as they become more common and more trusted, perhaps they just make phishing scams easier to pull off.

I’m not convinced these problems can be solved by technology; at least not by technology in the websites themselves.  I think this can only be solved by something that sits between the user and the trap – For example: the web browser, your ISP, or the HTTP protocol itself.

• Chrome and IE8 both offer a neat address bar feature where the host name is bolder than the rest of the URL making fake URLs much easier to spot;
• Firefox has more obvious server certificate and identity information, makes more of song and dance about invalid certificates and shows the host name in the status bar;
• Various browsers offer warnings of known scam URLs and no doubt many ISPs aid this effort

However, these features still require education and awareness. Above all, any solution requires the attention of the complacent masses who just want to get on with their life and click “OK” until they get what they want.

I noticed some weeks ago that Twitter’s OAuth implementation didn’t appear to be verifying signatures. I knew this because I purposefully set an invalid access token which was accepted unconditionally. I thought this was odd, but as a newbie to OAuth I was just happy that my app was working, so I filed the problem at the back of my mind under “deal with it if it becomes a problem”. Today (the week I release by beloved TwitBlock app) it very suddenly became a problem.

It seems that eventually they decided to fix the security hole, except they did it without telling anyone. In their defence this needed to be done quickly, and they were only going to be implementing what we all believed was already in place, namely the well-documented OAuth standard. The problem was that many people, including myself have publicly released apps that could never have been fully tested.

The damage was already done, i.e. broken apps in the public domain; but the clean up operation didn’t go well either. At the time of writing, no warning has been posted on status.twitter.com. The first we all knew about the change was broken apps, and disappointed users. A few threads popped up on this Google Group where devs banged their heads together to work out what was wrong with their code libraries. In my case I eventually tracked down the bug: The main cause of my broken library was that I was signing the full request URL complete with query string. This is incorrect, as section.9.1.2 demonstrates. A bug that, if I’d been able to test properly in development, would not have made it into production.

Twitter’s response

Although I’ve not seen an official response, I did see a post on the afore-mentioned Google Group by one of the Twitter API developers. He admitted that they did not approach the situation as they should, but this post may have been deleted because I can no longer find it. I shall post it if I find it again.

URL encoding bug

Another bug (which was not actually the main problem) is that PHP’s rawurlencode function doesn’t quite fit the bill. OAuth parameter encoding implements RFC3986 whereas PHP’s rawurlencode function implements RFC1738… the difference is that PHP will encode the “~” character. A simple fix is to retro decode the offending character, as follows:

function oauth_urlencode( $str ){
return str_replace('%7E', '~', rawurlencode($str) );
}