Antipatterns for sale. Twply collected over 800 Twitter usernames and passwords (OAuth can’t arrive soon enough) and was promptly auctioned off on SitePoint to the highest bidder.
Sign in with 
OpenID
Antipatterns for sale. Twply collected over 800 Twitter usernames and passwords (OAuth can’t arrive soon enough) and was promptly auctioned off on SitePoint to the highest bidder.
What's the snarky blog post title going to be when someone phishes Twitter users for their OAuth credentials? Two sides of the same coin.
Alex Payne - 2nd January 2009 19:50 - #
Wow. I hope that's someone posing as Alex. I really really do.
Because if the Twitter API Lead doesn't understand the difference in those two scenarios ...
::shakes head::
huxley - 3rd January 2009 02:17 - #
With OAuth it's the user's fault for falling for a phishing attack. Without, it's the Twitter API's fault for encouraging them to give away their credentials.
That was indeed me posting. I'm pretty sure I understand the difference between the two scenarios. Let's explore.
A username/password pair are "credentials". An OAuth token is "credentials". Both are virtual keys to a virtual house, if you will. Both OAuth and password-based authentication systems encourage the user to "give away their credentials". It's just a matter of the form and scope of those credentials.
The username/password key's major disadvantage is that it open all the doors to the house. The OAuth key only opens a couple doors; the scope of the credentials is limited. That's a benefit, to be sure, but in Twitter's case, a malicious application that registered for OAuth with both read and write privileges can do most evil things a user might be worried about: posting nasty updates on their behalf, following malicious users, un-following legitimate ones, sending people unpleasant direct messages, that sort of thing.
So, OAuth is an improvement, which is why Twitter will be supporting it, but it's not a magic security bullet. It also doesn't change the fact that someone could sell OAuth tokens, although OAuth makes it easier to revoke credentials for a single application or site, rather than changing your password, which revokes credentials to all applications.
This doesn't even begin to address the phishing threat that OAuth encourages - its own "anti-pattern". Anyone confused about this would do well to read Lachlan Hardy's blog post about this from earlier in 2008: http://log.lachstock.com.au/past/2008/4/1/phishing -fools/ .
Alex Payne - 5th January 2009 00:56 - #
@Alex: That's why some OpenID providers (like Yahoo which btw, doesn't work on this site) use personal badges that make authentication/granting landing page unique per user and hard to guess.
If I can upload or choose an image that gets shown beside granting request, it makes it much more difficult for phishers to replicate that page.
I would really like to hear though why it takes so long to implement OAuth, since I know it's NOT ineptitude.
Marko Samastur - 5th January 2009 14:28 - #
The idea that OAuth and OpenID teaches users to get phished is a theory, a theoretical concern without supporting evidence.
The fact that Twitter has trained users to freely give away their passwords is a fact, and the consequences are now very real.
Additionally there are a wide range of solutions to potential phishing threats raised by delegated auth model from security badges to better browsers, while there are no solutions that make the password anti-pattern secure.
Still I've been assured that Twitter's OAuth will be back on again very soon (9 months now since the un-publicized, not quite standard, but totally functional version was turned off), and I, for one, am excited. I've been sitting on my hands all year waiting for a chance to do a little Twitter hacking again.
kellan - 5th January 2009 14:42 - #
"The idea that OAuth and OpenID teaches users to get phished is a theory, a theoretical concern without supporting evidence."
It's not theoretical that mitm is a feature of both. I suspect this will out itself in the OAuth IETF work, assuming the OAuth community puts the work in to get it standardized.
"The fact that Twitter has trained users to freely give away their passwords is a fact, and the consequences are now very real"
That is theoretical. Why is Twitter responsible when an account holder gives their password to a service like twply?
I find myself agreeing with Alex and am tired of Twitter being the OAuth crowd's current whipping boy for the password anti-pattern, when OAuth doesn't actually do enough to remove the need for the pattern - or we really saying what Pownce did on the iPhone is good enough?
Bill de hÓra - 5th January 2009 20:25 - #
There are a number of types of MITM, and while it's possible to trick a user into giving you a set of OAuth keys, it's more difficult because the user will be asked to give permission to some application with a name, which will naturally arouse suspicions.
OAuth doesn't solve traditional phishing attacks, but neither does Basic Auth. Browser extensions that blacklist known phishing sites are basically the only approach that I'm aware of that actually work, and even then there are ways around.
As far as sitting-on-the-wire MITM, OAuth is resistant to theft of secrets and replay attacks, in case that's what you meant.
Twitter is responsible because they didn't provide an alternative method of authentication, and through the promotion of the API encouraged users to provide their credentials to 3rd party sites.
As more details become available, it seems what happened is that a Twitter administrator (i.e., employee) gave their password to a 3rd party site because their API requires it, which was then used to compromise Twitter's admin interface.
OAuth was started in large part expressly because I wanted to avoid a disaster like this. Insofar as we didn't get OAuth shipped while I was at Twitter, that's my responsibility, but in the interim they've not fixed the holes, and that's a problem.
I don't agree with Twitter being a whipping boy, and thinking that OAuth is a silver bullet helps no-one. However, OAuth is an extraction of best practices that are used to great success around the web. It's the best we've got --- if you know of something better, please suggest it.
Failing that, it's our responsibility as developers to ensure that the systems we develop are as secure as possible. They're never going to be 100% secure, but that shouldn't stop us from trying, and it shouldn't stop us from complaining when our data or accounts are at risk of theft or defacement through no fault of our own.
As regards the Pownce iPhone experience, I've seen no research to suggest that it was a bad experience. Netflix has a similar workflow on the XBox, except that you have to actually get up and walk over to a "real" computer. I don't know what their adoption rates are, but it seemed perfectly natural and easy to me to connect my NetFlix account (which I use from my computer) to my XBox (which I use with a joystick), and frankly logging into NetFlix on my XBox would have been weird.
Blaine Cook - 5th January 2009 22:43 - #
FLASHBACK: Can I take off my headphones for ONE SECOND around here without hearing the phrase "smoking a bowl"? - @al3x
http://icanhaz.com/r3ason
Todd - 5th January 2009 22:52 - #
It's not theoretical that mitm is a feature of both.
A paranoid individual can watch what is happening as they authenticate with Oauth. They can make sure the oauth site is the correct one (or have the browser do it for them).
As more details become available, it seems what happened is that a Twitter administrator (i.e., employee) gave their password to a 3rd party site because their API requires it, which was then used to compromise Twitter's admin interface.
Twitter employees could have made sure they were using the real Oauth endpoint. As is they had to give their passwords to every service they tried.
Jesse Andrews - 5th January 2009 23:02 - #
"Just an update. The database is not being supplied to the buyer. He wants the site for the traffic and he will use his own database."
- http://marketplace.sitepoint.com/auctions/54573
This lessens the immediate story impact but not the overall point, I feel.
Phil Wilson - 6th January 2009 00:43 - #
OAuth lets you do lots of fine-grained permissions. I'd love to be able to give tapulous the ability to read my private feed and post to my public feed without giving them the ability to follow or unfollow, for example.
The second problem with the password anti-pattern is people who use the same password in multiple places, which is itself an anti-pattern but still risks much.
I'm a total non-geek/non-developer, but 'just' a Twitter user. I've heard of the name OAuth, I know it's got *something* to do with security & websites - but that's it.
What I do know is that I've felt very uncomfortable giving away my password to 3rd party Twitter plug-ins etc...
If I - as a n00b - feel that something's fishy, all of you lot that come here as pro's should definitely be feeling that, esp. after yesterday (Britney et al).
I don't care what you do, but get it sorted. Not just the boys from Twitter, but the web-smart community that uses Twitter (and that's most of you, judging by reports) should get their ass into gear and provide a good solution!
antonie - 6th January 2009 06:59 - #
antonie: OAuth is basically like dbt said, a way to give other applications or sites partial access. Kinda like how you could give one person a key to your car that just opens the door, and another person a key that opens the door AND turns it on. Not that you'd do that, but you COULD have that kind of permission control with OAuth.
Oh, and you get a list of sites that have access and the ability to edit or remove that access. Meetup.com recently got OAuth support, which is real ace. And it didn't take long after someone requested it for it to be implemented, either!
@Tom: I had started to gather something like that. But thanks for explaining it so clearly!
However, my point wasn't for me to get more info on what OAuth is, but to give feedback as a user - so essentially as a representative of the vast majority of people using most of the websites that would need this security - declaring that
a. we expect this to be tackled already
b. you, geeks, need to get this sorted asap, so that
c. we can enjoy seamless integration without security breaches
antonie - 6th January 2009 09:44 - #
antonie said:
Then don't do it.
If users stopped using these services then the owners of the services might apply a bit more pressure to Twitter to get the situation fixed.
It's not as though any of these Twitter add-ons are essential is it? I have found many that I would like to try (but won't whilst I need to give them my login details) but none whose functionality is enough to justify the required breach of good security standards.
It's worth pointing out that Twitter's own T&Cs say "You are responsible for keeping your password secure". You can't give your password to a third party site without breaking that condition.
No one's claiming that oAuth's a "magic bullet", but it's so much better than the current scenario as to be a "no-brainer" requirement. The difference is that between the keys to a house and the keys to its postbox.
Twitter is a fantastic service that also has the capability to take the lead in API development and in authentication best practice. It's unfortunate that it's not taking that path.
I have to say I find Alex's attitude unsettling at best - I hope he'll accept oAuth for the improvement it is rather than running scared from it.
I don't think the password anti-pattern means anything. We had already learnt to give our password away. If I give my Google password to Outlook, it is because I am confident that it won't do some evil thing with it. I don't think it matters that the client run in the browser or on the desktop. Well for most users... Some can check that a desktop app does do anything bad with your password. It is really just a matter of trust for web app.
Said that, OAuth is a far better way to give credentials to a third party applications.
Indeed, and if Blaine is correct (and an admin user used his/her admin password on a 3rd party site), they'd do well to remember that their inability to follow security 101 compromises all of Twitter's users, and not just their account.
http://twitter.com/simonhamp
It's well and truly the responsibility of a service provider to enable a facility to allow it's users to control the level of use a 3rd-party consumer can have.
Applying the all-or-nothing principle benefits no one. I use twitter and develop plug-ins that use its API. As a user I don't want to give out my username/password combination! As a developer I want to be able to assure my users that their information is secure! Neither of these things are protected with the current API.
I don't care too much about it at the moment as I don't suspect foul play on the few consumer services that I allow to use my account. As a user I certainly wouldn't want to have to change my password and then update all of my 'safe' consumer services - too much hassle!!! If a consumer service is compromised, I just want to shut access off for that one! Much easier!
Simon: "It's well and truly the responsibility of a service provider to enable a facility to allow it's users to control the level of use a 3rd-party consumer can have."
This sounds like assumed obligation - let me put it another way - would you pay for that service?
Blaine: "Failing that, it's our responsibility as developers to ensure that the systems we develop are as secure as possible. "
I understand that, I hope you're trying to imply I think otherwise.
"it shouldn't stop us from complaining when our data or accounts are at risk of theft or defacement through no fault of our own."
Here's the rub - people *choose* the use the "services". I don't fully buy into the obligation aspect for the core service provider, and it's interesting we're not talking about the obligations of the 3rd parties - why is that?
"As regards the Pownce iPhone experience, I've seen no research to suggest that it was a bad experience. "
I think the UE issues here will be redirection and the fact that OAuth doesn't work like said password anti-pattern which most people know how to use. We engineer and early tech adopter types don't yet understand how confusing that might be - experience around OpenID is instructive.
Fwiw, I've implemented OAuth and I do like it. One problem I have is the rhetoric around password anti-patterns focuses on the wrong thing - not trying to understand fully what OAuth's own issues are. (I don't think that lack of introspection has helped OpenID very much). Another problem I have is that it's clumsy in non-browser scenarios, eg mobile as evidenced by pownce's app; it might be that there's no middle ground to be had here.
Bill de hÓra - 6th January 2009 15:07 - #
@Bill: "would you pay for that service?"... my answer: Hell no! That should be included as part of "the service" as standard, especially when there's such a great emphasis on developers making use of an API with that high level of access.
At the very least it is the moral duty of service provider to state clearly how unsafe the system they have developed is.
But of course that will just discourage potential users (and even some existing users) from experiencing the benefits of 3rd-party services integrating with their centralised information.
Unfortunately until Twitter and others like them see this problem from the very real financial impact perspective, nothing will be done.
This additional measure of security shouldn't be added on as another "service" that you pay extra for. That's not where Web 2.0 and beyond is going - if anything it's going in the opposite direction!
Twitter isn't a particularly great example, as the implications of a security breach are minor - even if it does make headlines. I will continue to use Twitter. And I will continue to give out my username/password to sources I trust. However if one of these services abuses my details I may have to consider leaving Twitter in favour of a more secure service.
Bill, I don't think Pownce represents the finally word in mobile authorization experiences, just the one that most closely tries to replicate the desktop based experience on the phone.
In OAuth tried to only standardize the absolute minimum number of integration points (the forces of good won some of those fights, and lost a few as well).
But that means a whole slew of creative solutions are possible, we just haven't seen much OAuth UX innovation yet. (for the record I count 6 distinct device auth flows for Flickr, depending on circumstances)
kellan - 6th January 2009 18:14 - #
This wasn't the case. The administrator account in question was compromised with a dictionary attack against the employee's password. We're taking steps to minimize the risk of a similar hack going forward.
Security of admin tools aside (God privileges outside of a secure network or w/o multi-factor (or at least multi-layer) auth? Hmm), I think it's still worth hammering home how bad, and how many ways of badness the password anti-pattern really is.
Kellan mentions this, but really it needs to be reiterated because for whatever reason it's not mentioned enough (and at the beginning of every mention of the password anti-pattern, because none of any of Alex's arguments even make any sense when you start there) - it's just a plain fact that people reuse passwords.
How many accounts across the web would the average Twitter login compromise. Half a dozen? More? How many of these would compromise a primary email account or otherwise escalate into full identity theft?
OAuth doesn't solve everything, but at the very least it would prevent: the ability for a compromised account to have their password or other account information leaked and changed, and allowing account name and passwords to be leaked (and forced to be stored by multiple third parties IN PLAIN TEXT).
It's somewhat strange, especially considering there was a working key-based interface last year that was turned off. It might not have been perfect, but it was a hell of a lot better than what's been going on since.
We're not talking about esoteric MITM attacks, just Security 101. I mean, reread those last paragraphs. That there honestly needs to be this kind of discussion at all is actually mind-boggling. I mean are we really arguing this? I mean, seriously?
No really, seriously?
...
Well, good luck with that.
Simon: "At the very least it is the moral duty of service provider to state clearly how unsafe the system they have developed is."
"And I will continue to give out my username/password to sources I trust. However if one of these services abuses my details I may have to consider leaving Twitter in favour of a more secure service."
Right now, I see no chance of you and I finding a common ground :)
Of course are free to leave Twitter, but as I mentioned, why is the 3rd party, or you, not also accountable?
Bill de hÓra - 6th January 2009 22:25 - #
Kellan: "I don't think Pownce represents the finally word in mobile authorization experiences, just the one that most closely tries to replicate the desktop based experience on the phone."
I agree, but the mobile world is funny place coming from the web. "Off web", people do think that a phone number is a strong (albeit transient) identifier and this stuff should just work without bouncing users between applications. I caricature this thinking as "you are your phone", but at one level it's no different to the way we think about credit cards "on web".
"for the record I count 6 distinct device auth flows for Flickr, depending on circumstances"
Interesting! Is there a place they are described?
Bill de hÓra - 6th January 2009 22:30 - #
lhl: "No really, seriously?"
Yes, really, because I think this is a usability problem. Which is why I can't agree when Simon said,
"Unfortunately until Twitter and others like them see this problem from the very real financial impact perspective, nothing will be done."
the passsword anti-pattern is too convenient. That's why it sticks.
"Well, good luck with that."
And good luck getting a service as popular as Iwitter *without* user/pass as the default!
Bill de hÓra - 6th January 2009 22:37 - #
Bill, if your concern is end-user confusion or your claim is that a service can not be popular (or have popular third party services) without using passwords, I think that Flickr is the obvious counterpoint.
(Fire Eagle's OAuth work flow also works quite well, both as a developer and end-user.)
I can understand where Alex is coming from, but I can't quite get your perspective... As a former developer of a service with a large user base, there absolutely is a moral and ethical if not fiduciary responsibility to keep accounts safe to the best of one's ability. Are you arguing that it's better to take a knowingly worse, and very dangerous and risky path, when there is a clearly better (not perfect, better) alternative?
No offense, but if I understand you correctly, I'll be sure to avoid any websites you work on.
Assuming the 27b/6 post at http://blog.wired.com/27bstroke6/2009/01/professed -twitt.html is trustworthy, I see some more security antipatterns worth noting here:
1. user account with admin privileges, instead of a role account;
2. access to admin privileges permitted without two-factor auth;
3. insufficient rate limits or other dictionary-attack defenses.
Justin Mason - 7th January 2009 13:11 - #
@lhl: "I can understand where Alex is coming from, but I can't quite get your perspective... As a former developer of a service with a large user base, there absolutely is a moral and ethical if not fiduciary responsibility to keep accounts safe to the best of one's ability. Are you arguing that it's better to take a knowingly worse, and very dangerous and risky path, when there is a clearly better (not perfect, better) alternative?"
No, I'm not. I'm arguing there are 3 parties and placing on the responsibility on one of them is overly simplistic in this case.
If we're talking about twply, then my point is that it isn't absolutely clear what Twitter's responsibility is with respect to 3rd party systems and users using those 3rd party systems, not enough to make moral statements (for me anyway) - at the very least to be consistent you're going to have to explain what the 3rd party's and the users' moral and ethical responsibilities are. I find the question, "should a 3rd parties ever build systems like this that require them to hold another system's username and passwords" illuminating.
If we're talking about the admin password, then I think it's completely separate; I'd agree with Justin, especially his points 1 and 2.
"No offense, but if I understand you correctly, I'll be sure to avoid any websites you work on."
I don't think you do understand me, no offense taken :) Specifically for third party systems, I encourage tokens over user/pass credentials. And please bear in mind none of this is an objection to OAuth itself. But I don't yet buy the argument there's a single point of responsibility here.
Bill de hÓra - 8th January 2009 14:12 - #