how to partition your google identity

with all the reports lately of vulnerabilities in google i suppose it's time again for me to talk about how you can mitigate the threat these vulnerabilities pose to gmail users...

i last wrote about this subject at the beginning of the year when a similar vulnerability was in the news, and i've also made my feelings on single sign-on and federated identity (the direction identity management seems to be going these days) pretty clear... these google vulnerabilities and those that came before illustrate the problem - the 'one account to rule them all' approach creates a hugely valuable (to attackers) online identity and single sign-on integration between web applications (like that which google or microsoft or any number of other players provide) makes it that much harder to mitigate vulnerabilities by following advice like "log out of gmail"...

so what if you're like me? what if you use more google apps than just gmail? what if you use blogger for example, or google reader, or google notebook, or google groups, etc... if you're like most people you use the same google account for all of them - your gmail account... it's convenient, you only need to remember one username and password, and when you visit an exploit page while still logged in to one of these other google web applications your gmail account gets pwned because logging into one logs into all...

now, of course you could always hope google fixes these problems before you get caught, or use tools like the noscript firefox extension that should be able to help most of the time, but you might not realize (as some security folks hadn't) that you can also use a non-gmail google account for those web applications... then, not only is it easier to stay logged out of gmail while using the other web applications, logging into the account used for those other applications will actually force you to log out of your gmail account...

it's really quite simple:

1. just head over to the google accounts page and create a new account using whatever non-gmail email address you want and presto - you have a non-gmail google account...
2. you probably already have data on those other google web applications though but that's not a problem because many of them have ways of sharing that data with other users (ex. google reader exports opml files that can be imported to a different google reader account, google docs and spreadsheets can be shared literally, blogger lets you add a different account as the blog administrator, etc)... those sharing facilities can make it easy to migrate that data from your gmail account to your non-gmail google account...
3. then all you have to worry about is remembering another username and password, or do you? i don't, i just use passwordsafe, then i only have to remember the master password and it works across all websites - even entering the username and password for me with the press of a key... in fact, password managers like passwordsafe work outside of the web too, for virtually any windows application that takes a username and password...

now you may have noticed i only described separating your gmail identity from your other google web application accounts - this is because right now gmail seems to be by far the most interesting target for attack (everyone seems to want your contact list or your emails)... you could just as easily have a different google account for each and every web application you use without having to remember anything extra if you feel your data or identity in the other applications warrant similar protection through compartmentalization...

what's wrong with identity management

this is something that's been nagging at me for a while and i think the cross site request forgery vulnerability in gmail from late last year/earlier this year underlines the problem... a single account for everything gives too much power to whoever or whatever compromises that account (whether by gathering the credentials or hijacking the session)... this isn't just a problem with google account, though, there was microsoft's passport, and of course the much talked about (these days) openid...

let's start with the reason for identity management, the motivating factor that lead to it's creation... there's some problem condition out there that pushed people to come up with the idea, supposedly as a solution (though perhaps not a good one)... that problem condition is that with so many sites out there requiring users to log on it's difficult if not impossible for users to remember all the username/password pairs for each of those sites... users, being cunning when it comes to finding lazy solutions, came up with the adaptation of using the same username and password for most/all of the sites they log into... the security problems with this are two-fold: first it creates a situation where instead of having different secrets (passwords) protecting different assets you have one login to rule them all, and second that single set of credentials is placed in many different databases (a different one for each site) which raises the probability that those credentials will get exposed by someone cracking into one of those databases...

identity management generally aims to move user authentication out of the hands of every tom, dick, and harry site out there and into the hands of a trusted few sites which then vouch for the user's authenticity to any other site that asks... this has the immediate benefit of storing user credentials at and conducting the authentication transaction through fewer sites (generally just one) so that the risk of exposure due to database cracking is reduced... unfortunately it still leads to a one login rules them all situation, and frankly database cracking is not the low-hanging fruit in identity theft - if you can do it you can certainly get a lot of credentials in one go, but it's far easier to compromise a user's credentials through the user him/herself by way of phishing or key loggers or a password stealer...

the problem that identity management solves is the same one that users solved by using the same username and password everywhere - it solves the convenience problem associated with many sites requiring authentication... it solves it a little bit better in that one particular type of attack surface (the remote databases) is reduced, but since it collapses multiple accounts down into one it leaves open (and actually promotes) the problem where the compromise of a single set of credentials exposes all your information and assets - and isn't that what the real problem with using the same username and password everywhere is?

the only real way to mitigate the risk of such catastrophic exposure is to use multiple accounts with different credentials - which may be possible with identity management but is definitely not the usage pattern it was designed for... the whole problem arises because using multiple accounts with different credentials isn't easy - everyone seems to want to solve that difficulty by simply not doing it, by finding a way around it, but there isn't one... client-side password managers actually do a pretty good job of solving that difficulty without simply avoiding it, but depending on the implementation those can have problems of their own...