Google Authenticator for multi-factor authentication

The security-conscious will tell you that a multi-factor authentication scheme involves requiring items from two or more of the categories "things you know," "things you have," and "things you are." Passwords and passphrases both fall under the "things you know" umbrella, and while there are commercially viable options for the latter two categories — security dongles and biometric fingerprint scanners, for example — neither have taken off with the general public. Partly that is a cost issue, to be sure, but the complexity of public-key infrastructure (PKI) smart cards does not help, either.

Late in 2010, however, Google unveiled an open source project called Google Authenticator that allowed the common smartphone to serve as the "thing you have" factor. The search giant subsequently rolled out support for the scheme for its web applications, but its standards-based functionality and Pluggable Authentication Module (PAM) support have brought it success in a variety of third-party systems as well.

Client

On the smartphone side, the Google Authenticator project provides application software for Android devices, Apple iPhones, and Blackberry handsets. Because these applications are software and generate authentication strings for the user to enter at login time, however, there is some question whether or not they truly "count" as a second factor. Traditionally, hardware authentication tokens must be physically connected to the computer to authenticate a user, though some one-time password (OTP) generators are standalone. Unlike the Android app, however, those devices are meant to make it difficult to extract the key without destroying them. Accessing the key from a phone, then running the app elsewhere (e.g. an Android emulator) would circumvent the "things you have" requirement.

The project's official tagline is "Two-step verification", a subtle acknowledgment of its distinction from a strict definition of multi-factor authentication. But to narrow that security risk, the system generates OTPs that are only valid for a short duration (generally no more than one minute). That does not stop an attacker who steals your device from getting a valid OTP from the application, but it makes it more difficult for an attacker to forge a login through eavesdropping. Specifically, it prevents replay attacks (such as wandering eyes behind you in line at the coffee shop jotting down the passcode) and makes interceptions (such as wandering eyes paired with extremely fast fingers) highly unlikely. Using an OTP will help against credential-stealing attacks, such as those used to compromise kernel.org.

Google Authenticator supports both the Hashed Message Authentication Code (HMAC)-based OTP (HOTP) and the Time-based OTP (TOTP) specifications, both of which were developed by the Initiative for Open Authentication (OATH). Both algorithms use a pseudo-random seed value or key that is known only to the server and the client; the seed is concatenated with a "moving factor" — the piece of the puzzle that makes the password one-time-use only — and the result hashed to create the expected passcode.

HOTP, the older of the two, uses an integer counter that increments for every new passcode. TOTP uses a timestamp as the moving factor instead, with provisions for the server to define whatever time window it wishes to accept as valid. That value enables humans to type in the passcode at a convenient speed, and also allows for clock drift between server and client. Although TOTP is regarded as more secure, HOTP is already finalized as RFC 4226, while TOTP was still at the draft stage when the Google Authenticator project was launched (it has since become RFC 6238).

The mobile clients provided by Google support storing multiple HOTP and TOTP credentials, and can be used to generate passwords for any compliant implementation of the algorithms. There are two mechanisms for entering the seed value associated with each saved account: devices with a camera can take a photograph of a key in an appropriately-formatted QR code, or the user can manually enter the key as a Base32 string.

Server

For the server side of the system, the project provides a command-line tool to provision new keys, and a PAM module — although "server" is not quite accurate; the module will work on traditional desktop Linux distributions as well. According to the user comments on the module's wiki page, Linux appears to be the only operating system supported out of the box; there is a patch reported to work on FreeBSD 8.2 and another for OpenSolaris, but no luck yet for Mac OS X or other PAM-supporting OSes.

The key provisioning tool is called google-authenticator. When run, it generates a new key (primed from /dev/urandom), along with a "verification code" and five "emergency scratch codes." The verification code is used by Google to associate an account with a cellular number via SMS message, and the scratch codes are eight-digit numeric strings designed for use in account recovery — neither is part of the core algorithm. The google-authenticator tool writes the key and the emergency scratch codes into the ~/.google_authenticator file. If libqrencode is installed, it will also generate a QR code formatted for consumption by the mobile applications — the format includes metadata for use by the application, including the hostname, user name, and key type ("totp" or "hotp"). It also writes a URL to stdout containing an HTTPS link to Google's online QR code generator, with the same information as the payload (although, obviously, using the online generator does send your secret key and user/host data to a Google web server...).

The PAM module is named pam_google_authenticator.so, and can be enabled by editing the PAM configuration file for the appropriate service (typically located in /etc/pam.d/). Simply adding

    auth required pam_google_authenticator.so

to, for example, /etc/pam.d/gdm will activate the Google Authenticator module for all accounts; it will request the HOTP or TOTP passcode after asking for the username and account password. Because the keys are stored in $HOME by default, workarounds are required to use the module with encrypted home directories. The project README recommends rearranging the PAM configuration to decrypt home directories earlier, or storing the keys in a different location (which must then be passed to the module as an argument in the configuration file line).

There is a patch available that will require the Google Authenticator module only if a .google_authenticator file is present. This approach could be used to partition accounts into "high-security" and "low-security" groups, but it could also come in handy if something goes haywire during setup. TOTP can handle a certain degree of clock shift, but the last thing you want to do is activate it for all of your login accounts before thoroughly testing it. To that end, the project also provides a demo utility for testing TOTP passcodes, and an interactive online debugger to ferret out clock and interval problems.

Authenticating in practice

Of course, the GDM example above is not Google Authenticator's intended use-case. Securing SSH and other remote-access methods makes more sense for those whose machines are safely tucked away in an office or closet; any attacker with physical access to a local login prompt has many other attractive opportunities. Any PAM-aware application can take advantage of the module, however — including Apache, which opens the door for many multi-user, web-based applications.

Indeed, there are already numerous third-party projects to integrate Google Authenticator into WordPress, Drupal, and other Content Management Systems (CMS), as well as instructions to use the PAM module for security-conscious packages like OpenSSH and OpenVPN.

Perhaps the more pressing question is whether or not it is wise to introduce a dependence on an application available only for iPhone, Android, and Blackberry devices. As popular as these platforms are, they still leave some users out in the cold, and there may be times when you need to log into a machine and your phone is unavailable for any number of reasons — from job site security, to accidental loss, to simple battery failure. USB security fobs do not suffer from the same limitations.

To that end, however, Google Authenticator benefits from the existence of other HOTP and TOTP implementations. While there are not many to choose from, there are a few: OATH Toolkit, multiOTP, and LinOTP are all free software. I tested Google Authenticator TOTP codes against OATH Toolkit's command-line oathtool. You can perform a passcode-generation hash by running:

    oathtool --totp --now="the_current_time" your_secret_key

The passcodes matched, once I figured out how to correctly convert the Base32 encoding produced by Google Authenticator into the hexadecimal required by oathtool — namely, that the Base32 encoding scheme defined by RFC 4648 is not the same as base-32 mathematical notation (because the encoding avoids easy-to-confuse characters like I and O).

Thus, there are options for users who cannot or will not carry a device with an official Google Authenticator client application. The availability of compatible command-line options is not a completely secure solution for the lost-phone emergency scenario, though, because it requires you to store the secret key in a third (or fourth, or fifth, etc.) location.

Nevertheless, as the CMS extensions and wrappers for various languages demonstrate, the Google Authenticator project has taken off to a degree that other OTP utilities have not (and there are several using other algorithms, including OTPW and Mobile OTP, both of which have PAM support). That makes the project a net gain for system security, perfect multi-factor authentication or not. The code is packaged for Debian and Ubuntu, and there are contributed builds available for OpenSUSE and Fedora, although there does not appear to be an official package for either of the latter distributions. If the distributions come on-board in force, perhaps OTP adoption will one day be commonplace.

Index entries for this article
GuestArticles	Willis, Nathan

---

to post comments