Keeping your single-serving passwords under control.
If you have a Google Apps account, or even a regular Gmail account that you use for email and watching the colorful tumbleweeds on Google+, you should activate their two-factor authentication service.
When you setup multi-factor authentication like this, it works great for applications and services on the web. But what happens when you want to use a mobile device or desktop email client to access your Google account in something other than a browser? Not all applications support an additional authentication method or can even prompt you for a one-time code. Do you use iMessage, Beejive or Verbs for instant messaging? Do you need to configure your CalDAV account for your calendar software? Google allows you to create an application-specific password so that you can let that application or service communicate with Google and login using a strong password designed to allow access to your account without trusting them with your account password and bypassing the requirement for 2-step verification.
This has a couple of benefits, namely that should your account be compromised in this way you’ll have a pretty good idea of how the intruder gained access. Google makes some recommendation for naming these application-specific passwords, but I have to say that using their recommendations may make it harder to dig it up later if you’re anything like me and regularly replace/re-image or rebuild devices and systems.
Because I’m smart, I use 1Password for OS X and iOS so that my passwords, software licenses and account details are safely stored2. When I create an application password at Google I always store it in 1Password so that I can recall it later if I need to put the password in again. You can very easily end up with a mile-long list of passwords if you’re not careful, so in general I recommend the following practice:
How to 2-step like a champion
Name your application-specific passwords by device name or application name, followed by a forward slash ‘/’ and the account that it’s associated with. You’ll thank me later.
Here in this list you’ll see a list of ‘$computer’ or ‘$device’ names, and one example of a ‘$service’ account: ‘altomail/’, for the beta of AOL’s new webmail client, which can access my Gmail account using the username and that single-serving password.
Device or Computer sounds unsafe. Why do that?
It’s certainly better to have different passwords for every application that needs to access your account, but not always necessary. I’d suggest using a similar strategy for naming them;
$app/$device/$account. The drawback to this is that it’s disproportionately a hassle and it’s more effort to revoke them later when you really need to because you have a higher chance of nuking the wrong one, or missing one. Having a consistant naming convention helps a great deal with this, so it’s really up to you to weigh the benefits and level of effort.
Why would you want to revoke them?
Well, because if your iPhone, iPad, or iPod is stolen, it’s easy to revoke the access that device has to your accounts by nuking it with Google and bam, the person that has my device can’t impersonate me or rifle through my online accounts using that password. I always have device-level encryption on my devices, and I can just wipe the device remotely (and I will) but if they can’t use the device, it may not ever get on a network, and therefore it may not ever get my remote wipe command. At that point, I’m concerned about an offline attack to recover data, so I need to make sure those details aren’t useful anymore and I don’t want to have to re-key every single application and device I own unless I have to. You don’t either.
One big benefit to individually authorizing and provisioning using the
$application/$device method is that it somewhat isolates other services and devices when one set of credentials is compromised. Given that many apps and services for mobile devices utilize push notifications and maintain persistant connections to do so, it’s often to your advantage to create a dedicated password for those services3
What about 1Password then?
When I set up my Gmail account, Google+, Verbs, Google Voice, Reeder and a bunch of other apps on my iPhone, I can just use the same application-specific ($device) password on all of those apps: the one marked ‘annyong/’. Since I use a clever naming convention on my two-step it’s wicked easy to search and recover that password every time I need it. I can then Copy-Paste it from 1Password into the other app. I can search for my device or computer name, and it comes right up.
Obviously any trusted password manager you use will work for this, but 1Password is the best-in-class so that’s the one I use. It’s mine; I’m a fancy boy.
Don’t make it too hard
There are many people that don’t bother with two-step auth on their Google account because it’s too much hassle, or tedious to get these application passwords set up. This method I’ve outlined should make two-step authentication tolerable and still give you enough protection and isolation that if a device is missing/lost/stolen or your computer needs to get re-imaged or replaced, it’s a lot easier to get back up and running without having to replace a dozen passwords every time.
I previously wrote a little bit about the technology Google uses for this when writing about Dropbox’s two-factor option. If you are using iOS and Authy it’s easy to add your Google Account(s) to Authy in addition to your Dropbox account and any other service you subscribe to that allows you use a TOTP token. If you use Duo Security which lets you do sweet multi-factor access via push notifications, SMS, and voice calls, you can also add TOTP tokens for Google, Dropbox, and other services! ↩
1Password also makes it trivial to export a list of items tagged ‘household’ for your partner to import into their 1Password database, which is a real sanity saver. ↩
In particular IM+ and Beejive messengers maintain lengthy connections to IM servers on your behalf so that they can send notifications to your device without requiring the app to be running. ↩