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
- 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.
Application-specific passwords
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…is there a better way? More convenient? More secure?
I use different passwords for all critical systems, like e-mail and banking; they are not repeated from site to site. For less critical things that would be less annoying or damaging to have hacked (goodreads.com, for example, or twitter), I use simpler passwords- again, not the same ones that are in use elsewhere.
However, this method means I accumulate an excruciating number of passwords. This is especially true of me at work, since I have to use different unmatching passwords for various systems that afford me huge access to other people’s data as well- being a systems administrator means having to be security-minded at all times.
The answer to this is simple, though- for passwords that are not super-duper sensitive, I use LastPass- it saves my login credentials for all the less sensitive stuff. For the more sensitive stuff, I keep an encrypted password list- in the event that I cannot remember one of the passwords (which is rare), I decrypt the list and review it there.
Of course all of this is just biding time until my passwords are simply dna-encoded so nobody can use them but me.
Hmm, LastPass… is that browser-based?
You’re joking about the DNA-scanner to some degree, but what about other biometrics? We already know finger-print authentication is a viable option for some hardware and some software, but it’s far from ubiquitous, at least for now.
Based on your experience I switched on 2-stop authentication for my private account yesterday (I had known it existed but didn’t know about the Authenticator app that works offline). Works pretty much as advertised. Doesn’t work with the current version of Mailplane, my client of choice for following multiple accounts, but I can live with that. I’ll probably switch my work account over as well.
I like 1Password as an encrypted password store, I then have everything handy on iOS as well. As for banking, I feel fairly secure with smartcard-based HBCI, a card reader and a dedicated client.
I watch too many CSI-type shows, so I can think of several possible gruesome ways to overcome both fingerprint and DNA authentication. :-)
Interesting! I’ve never heard of Mailplane, thanks! It might be just the thing for Mrs. 1976 and her multiple Google mail accounts. She currently keeps different Gmail accounts open in different browsers in order to keep them separate, but she might like a unified approach better.
I dug this up about Mailplane and Google’s 2-step verification — did you already try that?
That tip is how it’s supposed to work, but two-step auth is broken in the current version 2.5 of Mailplane. There’s a beta of version 3 where it works, and I’m trying it out now (integrates Calendar, Docs and Reader, kind of nice, actually).
Thanks for the very helpful information. Looks like I will be making some changes.
[…] have elaborated on a few methods of personal information security before (here and here). I still prefer […]