If we accept that account information is regularly and inevitably going to be exposed, as the litany of recent breaches suggests, the next question is how to design a system’s security to survive it.
You can tell your users not to reuse passwords, but you cannot actually force them to do so (not knowing what they are). Also, at some level of scale that expectation is unrealistic without resorting to master password lists, increasing the stakes of that information’s exposure. “One password to rule them all” is great, if you don’t mind making everything dependent on your master list/system. Where would you keep it? On your laptop that never fails, that iPhone you never lose or that desktop at the job you’ll have forever? Allow yourself a half-second to consider keeping it on all of them before returning to the premise that we’re trying to improve security.
Mnemonic systems (e.g. based on something like the date of account creation: “YYYYMM[my initials]”) might be useful, with the downside of predictability. Picking an inscrutable mnemonic that nobody else knows is probably the best approach, but honestly, the world where users can be expected to be able to individually create, remember and reliably perform cryptographic functions in their heads is a totally different security universe than the one we live in.
One is not enough
The problem boils down to a static username and password alone being an insufficient threshold. The only factor in this method of authentication is “something you know.” We’re very familiar with other methods of authentication, like car keys or ATM cards being “something you have”, but how do we add them to systems that are served up by browsers around the web? The established model is to give the user something to have, namely a password generator: for example, Amazon employs a very affordable ($13) Gemalto Ezio device for use with their hosting environment’s multi-factor authentication. If you are staking the operations of your library or your clients libraries on EC2, on a simple cost/benefit, you certainly should use Ezio. There are plenty of other similar options, including RSA’s SecureID, if you want to roll your own.
What goes into each device is essentially a small operating system, software and secure storage. The software is able to use a unique identifier from storage to produce a deterministic new string on a regular interval (typically every minute). But a newer model has emerged from the realization that users already have uniquely identified hardware with an OS, namely their mobile phones, needing only the software for completion. Now you can save $15 and a few days shipping by just installing the app of your choice:
- RSA SecureID: iPhone or Android,
- Google Authenticator: iPhone or Android,
- Battle.NET Authenticator: iPhone or Android,
- and the rest: iPhone or Android.
So while you’re waiting for work to approve or integrate mutli-factor, or just finish moving everything to the damn cloud already, you can at least secure your Google account (or even protect your Warcraft Paladin) against unwanted access.
For me, my Google account is the core of my online life, having used Gmail and Documents at two previous jobs already. Calendar, Picasa, Groups, Reader and the many sites featuring Google integration are all dependent on it. Almost all my online accounts are linked back to Gmail. Even the local community radio station I volunteer at automates its broadcast off of feeds assembled by Reader. So the chance to add another layer of security for free is one I am quite happy to utilize and recommend.
Details
Not every application that hits Google is equipped to handle multi-factor authentication. As a workaround, Google provides long-form application-specific passwords. This is a well-tailored solution inasmuch as it allows old apps to keep working without risk to the rest of your account.
Google can also remember authorization from a given machine for up to a month, so you won’t have to keep tapping the app every time you sit down on your main systems. To avoid the problem of losing your phone, having your battery run out, etc. you should print off and stash some 1-time use verification codes. There are also fallback options for sending codes to a secondary phone number. Make sure you go through all the configuration steps before throwing the switch, or else you may effectively secure your accounts against yourself.
See Also
For additional reading, and as a next level of functionality for your servers, check out my emerging favorites, Duo Security for their mobile-based solutions including the ability to authenticate via touch-tone when their servers call your phone. Very cool, no app needed!
2 Responses to Adding two-factor authentication to your life