FreeOTP multi-factor authentication

Back in 2010, Google rolled out multi-factor authentication for its services using an open source project named Google Authenticator. The system generated one-time pad (OTP) passcodes on a mobile phone; users could log in to their favorite Google service with their usual password plus the passcode. In addition to its availability on Google servers, the open source project included a PAM module that Linux users could run on their own machines. Sadly, Google Authenticator fell victim to the gradual move toward proprietary code of recent "Google Play Services" releases and the open source version was discontinued, without fanfare, in 2013. Fortunately, the community has picked up the challenge and is developing a workalike called FreeOTP.

As we saw in our look at Google Authenticator, the system consisted of two halves: a mobile application and a server-side authentication plug-in. When provisioned with a key, the mobile app generated either HMAC-based OTP (HOTP) or Time-based OTP (TOTP) passcodes. Since HOTP and TOTP are both open IETF standards, the app could be used with any compliant server and supported storing multiple sets of credentials—the only prerequisite being that the phone would needed to be provisioned with the key for each service. The server-side tools included a key-generation program, and the project was popular enough that multiple third-party projects and web services deployed it.

The turn from free software to proprietary software came after the 2.21 release. The notice for the change was posted only as an update to the Google Authenticator web page at Google Code, which was highlighted in this Reddit discussion from May 2013. The wording change noted simply that the subsequent, closed-source versions of the app "contain Google-specific workflows". FreeOTP was started in August 2013; although it includes bits of code from Google Authenticator, it is predominantly a fresh rewrite—albeit one that does its best to serve as a free-software clone of the original.

The new project is hosted at Fedorahosted.org, and is maintained by Red Hat's Nathaniel McCallum. On the mobile side of the equation, it replicates the Android and iOS client apps, but drops the Blackberry variant. As of right now, the iOS app has not yet been published on Apple's app store, but the Android version is available both through Google Play and through the free-software repository F-Droid.

On the server side, so far FreeOTP is not producing any components. Since any standards-compliant HOTP or TOTP server should work with FreeOTP, there is no absolute need for the project to produce its own server-side code. One of the nice things about Google Authenticator and FreeOTP, of course, is that the server and the client do not talk directly to each other: the client app generates the passcode, then the user types it in. Still, this does mean that the HOTP/TOTP Linux PAM module is now unmaintained. Although it is likely to work, that likelihood certainly comes with no guarantees—particularly since system security is at stake.

The FreeOTP project site points users to FreeIPA as a recommended solution. FreeIPA is an identity-management suite offered by Red Hat that glues together several existing open source components to provide LDAP, Kerberos, RADIUS, and other authentication or authorization services. McCallum, unsurprisingly, works on FreeIPA, and has added HOTP/TOTP support to MIT Kerberos. Work is also underway for a standalone HOTP/TOTP implementation in FreeIPA, though it is still under development.

Two-factorization

FreeOTP replicates the same general workflow used in Google Authenticator. The first step is to provision the device with the key necessary to generate the HOTP or TOTP passcodes. How this step is done varies depending on the service one is trying to connect to, but the simplest option (if available) is to photograph a QR code that is generated by the server; these QR codes encode the key as well as the metadata one needs to keep track of the account (e.g., the server and account username).

FreeOTP is not as visually polished, but it does score some points over Google Authenticator by including the ZXing QR code–reading library within the app; Google requires downloading and installing a ZXing app separately. For services that do not generate QR codes for key provisioning, FreeOTP allows the user to manually enter the key, the key's options (e.g., the hash algorithm used) and information for the issuing service.

Once provisioned, opening the app shows a list of the saved accounts, and opening each account reveals the current one-time pad passcode. TOTP, the time-based passcode variant, is designed so that the codes are only valid for a brief interval of time (say, 30 seconds). The FreeOTP interface displays a little clock animation next to each code showing how much time remains, and automatically updates to the next passcode after every elapsed interval.

In practice, TOTP seems to be considerably more widespread than HOTP, presumably because HOTP seeds each passcode-generation run with a counter, rather than the current time, which in turn makes the resulting passcode valid for an indefinite length of time. This is of concern for Google Authenticator and FreeOTP because passcodes generated on phones can be compromised—a passcode with an indefinite lifetime allows more attack vectors than one that expires (for example, by jotting down the code and leaving, instead of stealing the phone).

But that is not the whole story; using one's Android phone as if it is a hardware crypto-token is a bit of a fudge regardless of the passcode-generation technique. In reality, since a phone can easily be lost or stolen, the only protection against the attacker using it to take over one's HOTP/TOTP online accounts is securing the phone's contents itself: password-protection, encrypted storage, and so on. What percentage of phone users actually take advantage of these options is anyone's guess.

For those who are concerned about the security of the device itself, it is worth noting that neither the Google Authenticator nor FreeOTP apps are password-protected. In an email, McCallum did mention that encrypted key storage is on the to-do list, but that other items (such as getting the iOS app released) have taken precedence for now.

On the other hand, many (or perhaps most) security schemes can lead into a "the perfect is the enemy of the good" cycle of disagreement that has no simple answer. Usage of two-factor authentication, even if the second "factor" is a software-generated passcode on a phone that could get stolen, is an improvement over user passwords alone. Similarly, while FreeOTP does not offer an expanded feature set over Google Authenticator, the fact that it is open source and thus auditable makes it a better option in absolute terms.

The shift of Google Authenticator to a proprietary app was certainly a step backward for the security-conscious, so it is good to see an open-source alternative arrive with feature parity. Of course, the mobile apps only cover one half of the problem; there is more work that remains to be done implementing multi-factor authentication on applications and servers.