It's been almost five months since I implemented what I then called Google's two factor authentication. My original enthusiasmwaned significantly as I better understood what Google had done, and how they'd stalled.
Now I'm in a more or less grumpy but stable relationship with Google's "1.4 factor" security model. I wouldn't call it "enhanced" so much as "alternative". If you're not careful, you may end up less secure than when you started. It is definitely not for everyone -- indeed, it's for hardly anyone who uses anything but Google's web UI to access Google services.
I'll share here how I currently live with what Google calls 2-step verification. First, I need to explain what it really is. Disregard Google's labels and descriptions; they're dangerously misleading.
To begin with, consider two kinds of access to Google Services (mail, calendar, documents, etc):
- Browser based access to Google's services (Ex: Google Docs, Gmail, Google account, Plus, etc)
- App based access to Google's services (Ex: IMAP/Mail.app, G+/Google Plus.app, Calendar/Calendar.app)
When you sign up for "2-step" you get two kinds of authentication for browser based access to Google services and one kind of authentication for App based access (including many of Google's iOS apps, such as the brand new blogger.app [1]).
Yeah, it's a mess.
There are two kinds of password/token access to Google's browser based services, including the ultimate service -- your Google account security controls:
- Combination of a standard user-defined password and a token (app created or SMS messaged)
- "Break the glass" emergency one-time use verification codes for when a token is lost
For App based access you use your Google Account to create one or more long (high entropy, secure if not captured) passwords. Contrary to Google's descriptions, these are not application specific. They're just alternative passwords for non-web services. You can create one and use it for fifty apps (iOS, OS X, XP, multiple machines, etc, etc) or you can create fifty. You can revoke these, but good luck figuring out which to revoke. In practice, if you think you've been compromised, you have to revoke them all. (It's possible that if Google thinks you've been compromised it would revoke only the password used. I'd still revoke them all.)
These Google-generated passwords are powerful. You can't use them for browser access, and you especially can't use them to get to Google Accounts, but you can use them for API access to all mail, all calendar, iOS access to Docs, etc. The more you create, the harder it is to keep track of all all of them, and the more vulnerable you are. Most of us, however, need these. Often.
So here is what I now do
- On my work machine, which is not a trusted machine, I use only web access and I require Google to ask for a token at all times. (There's a bug though. Unpredictably Google will decide to trust the machine for a month. As I mentioned, Google seems to have lost interest in 2-step! Even on a "trusted" machine, however, you need a token to mess with security settings.
- On trusted machines, including my OS X personal machines and my iOS devices, I use the same Google generated password for all apps. I create it once and store it in my encrypted 1Password database. (In the past, before I realized how this worked, I created many "app-specific" passwords. I'm gradually removing those to improve security and simplify revocation.)
See also:
- Gordon's Tech: RIP Password - Google's two factor authentication
- Gordon's Tech: Implementing Google's two factor authentication
- Gordon's Tech: The massive security hole in Google two factor authentication
- Gordon's Tech: Google's two factor: Three weeks later
- Gordon's Notes: Google's two factor authentication and why you need four OpenID accounts
- Gordon's Notes: Life with Google Two Step Verification - Sign-in Failed with Places.app
- Gordon's Notes: The New York Times' bad password advice - and what you should do instead
- Gordon's Tech: Google Chrome sync does not work with 2-step verification
- Gordon's Tech: Google's 2-step verification is the spawn of Satan - iPhone upgrade edition
-- fn --
[1] Wrong! It actually follows a newer practice. It uses a web UI for login. When you try a generated password it requests the browser password then redirects to a (crude) web UI for token entry.
2 comments:
I chose the same solution, 10+ so-called app-specific passwords were simply not viable.
On my wishlist is the possibility to generate my own app-specific passwords. My own passwords are usually more entropic than those by Google based on characters and numbers only (I have used the Diceware system for years).
Yes, that would be an improvement; though the generated passwords aren't bad. I'm much more concerned about keystroke loggers than I am about password cracking.
Post a Comment