Twitter's new OAuth Problem
dabr oauth security twitter · 4 comments · 550 words · read ~461 times.
Twitter have announced that all third party site will have to use OAuth. You will no longer be able to just type in your username and password to get access to Twitter via your favourite web client.
Usually, I would be a big fan of this move - especially if it forces password anti-pattern sites like TwitPic to implement the new, secure standard.
This means that you won't be able to log in to a third party site by giving them your username and password. You will have to use OAuth to securely validate with the main Twitter site.
But - as ever - there's a dark side to OAuth.
Repressive Regimes
One of the joys of Twitter is that its clients are decentralised from the main site.
This means that if Twitter is blocked in your country, you can use a third party client (like Dabr) to access it.
Twitter User -> Dabr -> Twitter API -> Dabr -> User
If Dabr became sufficiently popular to be blocked by an oppressive regime, you can switch to any one of the thousands of Twitter web clients.
OAuth forces you to the main Twitter site. While you may visit Dabr to start with, you would be redirected to Twitter to complete OAuth. If Twitter is blocked, you can't connect.
At a stroke, Twitter has shut itself off to anyone in a repressive country.
This has been picked up by some concerned users.
A (Hacky) Way Around It
There's really only one way around this problem. The third party web client has to act as a man-in-the-middle. There's a patch for Dabr - developed by cnyegle - which will ask for a username and password, then proxy it to Twitter, get the OAuth token and tweet on behalf of the user.
From the user's point of view, they are still giving the (potentially untrusted) site the username and password.
Challenge Response
This could be solved by implemented a challenge / response system.
- Alice visits the Dabr website.
- Dabr asks Alice for her username (and only her username)
- Dabr asks Twitter for the challenge associated with Alice's username.
- Twitter checks that Dabr is an authorised website (i.e. has signed up for OAuth).
- Twitter returns the response: A secret phrase which Alice has previously chosen.
- Dabr displays this phrase to Alice.
- Alice knows that Twitter trusts Dabr
- Dabr asks Twitter for the password challenge.
- Twitter returns that it requires the 3rd, 5th and last character from Alice's password (the characters requested change randomly).
- Dabr asks Alice for only those characters.
- If Alice provides the correct characters, an OAuth token is granted to Dabr to tweet on behalf of Alice.
This has the advantage of proving that Dabr is trusted (by displaying Alice's pre-defined secret phrase) and mitigating the risk that Dabr is untrusted (by only revealing part of the password).
Conclusion
This is a very new area, and I've not had a chance to read through all of the proposals. Nevertheless, it remains a fundamental problem that, if you can't access a site, you need to delegate your trust to someone else.
I'm not a security expert - so I would appreciate someone pointing out the flaws in my reasoning.
Isn't this just renaming password to secret phrase and making it so you only have to know a few characters of it?
No, it's fundamentally different - but I haven't explained myself well.... Take the following user journey.
Abraham visits Example.com - which promises to be the best Twitter client ever. He types in his username and presses enter.
(In the background, Example.com passes the username & a secret token to Twitter. Twitter checks that the IP of the request matches the token (much like OAuth). Twitter sends back Abraham's pre-arranged secret and asks for the 3rd, 4th and last character from his password).
Example.com displays "Your secret Twitter pass phrase is 'Moscow geese fly south for winter'. Please type the 3rd, 4th & last character of your password."
Abraham is satisfied that Twitter thinks this site is genuine.
He types in "ssd"
Example.com passes that to Twitter and - if satisfactory - gets back an OAuth token.
So, Abraham doesn't have to remember anything more complicated than his username and password - like now. He doesn't have to expose his entire password to Example.com. If he's stuck in the Duchy of Grand Fenwick - a repressive regime - he doesn't need to visit Twitter.com to authenticate himself. He is also immune to phishing because his pre-arranged secret (which he can change & is independent to his password) can only be retrieved by a trustworthy site.
Does that make a bit more sense?
Since it takes 2 minutes for anyone to register an application with Twitter there is no added protection that the application can actually be trusted.
At that point you are trading the security of not having to entire your entire password for insecurity of it only taking three characters to gain access to your account.