Information security is a PITA. But less so than not having any. What measures do you take to keep your online stuff safe?
I’ve written about some simple steps I’ve taken to improve the security of my online stuff before. The video below describes an extra step you can take if Google is a provider of a service you use (Gmail, Google Documents, Google Maps, etc.). My thanks to @Yellifers for tweeting about this article, which called my attention to these options. Apparently Google has offered these for over a year, but I’m just now hearing about them. I’m using them now to try to reduce the odds of nightmarish Google Mail filter manipulation to hide someone’s nefarious online activities about me from me.
Watch this video. It’s only three and a half minutes long. It describes the implementation of these extra security measures pretty well.
I think the steps mentioned above are a nice add-on to the concept I’ve mentioned before: make sure each application (program, website login, etc.) has its own password and there is no chance for any of those logins to overlap. The application-specific passwords Google generates for you for indirect access to your Google account guarantee that. And the time-based tokens for direct login to Google stuff throw an extra dimension of variability on top of that (since they expire every thirty seconds).
Prerequisites are a mobile phone or landline phone. And if you’ve got a smartphone (including an iPad or an iPod touch, like me), you can use that instead of the mobile/landline phone most of the time. If necessary (because you’re token-generating device is dead, and your mobile phone doesn’t have coverage at the moment, or it’s also been lost/stolen) , you can fall back to the old-fashioned (and arguably most secure) method of authentication: codes you print out on paper and take with you while traveling, or in your safe.
Let’s split this into two separate topics:
- One-time use tokens — Verification Codes
- Application-specific passwords
One-time use tokens
Near as I can tell, it’s basically the same concept as those RSA key fobs we used to have to carry around in order to log into corporate networks remotely:
- a device knows what time it is
- it calculates a one-time-use code — the token — based on the time and some other piece of information it knows about me (like my Google Account email address)
- Your username and password are not enough to verify your identity — that token is now required as well
- Effectively, this means your Google Password changes every 30 seconds
In this case, Google is performing the role of the RSA token key fob thingy and sending out the generated codes via SMS text messaging (or presumably automated voice calling, though I haven’t tried it, so maybe I can expect Larry Page or Sergey Brin to call up to say hi and read me a six digit number) to a phone number you told Google is yours. Or you can install an app for your smartphone to do the token generation for you, without need for reception of a text message on your phone. This is great if you get charged for incoming text messages or are using Google services somewhere without good cell tower coverage.
You log into whatever Google service you want to use with your normal Google username and password, and then the are prompted to enter the six-digit code from your Google Authenticator app on your smartphone, or have an SMS (text message) delivered to your not-so-smart phone. You have the option to allow Google to consider that “computer” (that’s their terminology; I think “user+browser combination” is more precise here) “trusted” for 30 days. This means you won’t have to consult the Google Authenticator app or receive a text message on your phone or get a call from Larry/Sergey for a month. After that, you’ll need to do it again.
This method puts to bed so many of my fears of using that (potentially filthy) computer in the hotel lobby while traveling, because even if it is infected with a keylogger and can snag my password, it still doesn’t receive the text messages to my phone or have access to my Authenticator app.
I use Apple Mail on my Macintosh computers (and the Mail app on my iPod touch) and Thunderbird on my Linux computers to read my Gmail. I use Apple’s Messaging app on my Macs and various IM clients on Linux to take advantage of Google Talk’s chat capabilities. If my Google Password is effectively changing every 30 seconds, these applications theoretically need to store my username, password, and the token every 30 seconds in order to authenticate me.
That’s just not feasible. Instead, Google has introduced application-specific passwords, which are also one-time use — sort of: Google only shows them to you one time, but the apps requiring your Google password will use them as often as necessary until you revoke them through your Google account settings. They’re 16-character strings, separated with spaces for ease of use. You might notice that if you copy & paste the string from your browser window into the application needing your password, it’s only 16 characters — the spaces aren’t copied, and they really don’t matter in terms of data-entry. This must mean that authenticating piece of software on the Google end is removing any spaces in the string sent by the client, since I’m sure Apple Mail or Thunderbird isn’t taking the spaces out of the password field that I’m entering.
So far, I’ve created about 10 application-specific passwords, and I’ve not seen any punctuation characters or numbers in use. I guess they’re relying on the length of the string to provide enough entropy to keep the passwords from being guessable, à la Correct Horse Battery Staple.
So…is there a better way? More convenient? More secure?