Two-factor, or what is often called Multi-Factor, Authentication is definitely the best way to defeat hackers because they render stolen passwords almost useless.
But what are these devices? How do they work? And do they have any security vulnerabilities?
The basic idea is simple. Instead of just requiring one password to log on to a website or app, TFA asks for another code that a hacker is not likely to have, since they are not likely to have stolen your cell phone as well as your password.
The one-time code can be as simple as a plastic card printed with valid codes that one keeps in their wallet. Or it can be an SMS (text message), a voice phone call or a code generated with a HOTP (HMAC, Hashed Message Authentication Code) or TOTP (time based onetime password) app, like the Google Authenticator (Google has developed a new standard too called FIDO U2F in conjunction with Yubico. We explain that below). Or, it can be a card, like a RSA SecurID.
The way the authenticator and code-generating cards work is you either enter a secret code generated by an app into the Google Authenticator (or equivalent product from other vendor), or you scan a QR code, which does the same thing, which is to sync up the device with the website. That establishes a trust relationship and creates a secret key that can be used to generate a login code.
The hashing algorithm generates a code on the server end and shortens the lengthy code to 6 or 8 digits. Then on the client end, the user types in the same 6 or 8 digit code.
In the case of TOTP, the generated code is valid for 30 seconds. But people are slower than computers so the algorithm checks different intervals of time -x seconds thus letting users use one that just expired.
But they will not work if the clock on your cell phone is off by days. The server keeps the correct time using the NTP (network time protocol) built into Linux and most other OSes. The cell phone should get the correct time from the cellular provider. But the user can turn off that feature.
HTOP is different. It is counter and not time dependent. Instead, it uses the secret key and a counter to generate the passcodes. These tokens do not expire. But that must not generate any security concerns as HTOP still has many followers, users, and products.
As to security, both algorithms truncate the lengthy hash created to 6 to 8 digits. The authors of the HTOP standard say that the generated 31 bit code is completely random, while truncating it and doing other math operations to shorten it to 6 digits. ‘These final steps introduce a negligible bias, which does not impact the security of the HOTP algorithm, in the sense that the best possible attack against the HOTP function is the brute force attack.’
The Google Authenticator is one of the most popular authenticator devices. Windows has one. The Facebook app can act as the authenticator for the Facebook web page.
When using these, the user is supposed to write down recovery codes in case their device is lost or stolen. Obviously, writing that down in a Google doc when you use MFA with Google Docs is a bad idea as you could lock yourself out. One idea is to use openssl to encrypt the document where you store such things and upload it to Dropbox and do not use TFA there.
Google has now made parts of its authenticator proprietary, while they maintain the opensource repository here. FreeOTP took a fork off that code and wrote their own authenticators for cell phones. They keep their opensource OTP algorithms on Github.
For the server component, in case you want to build TFA for your own app, they recommend FreeIPA.
There are many frameworks that support the OTP protocols, like this one for Python.
As an example of how these frameworks make something that could be complex simple, here is all it takes to get a passcode using Python:
import onetimepass as otp
my_secret = ‘MFRGGZDFMZTWQ2LK’
my_token = otp.get_totp(my_secret)
The standards and the frameworks use the name otpauth, which sounds too much like oauth. Oauth is a different technology that lets people login to different web sites using their social media accounts. The two ideas are not related at all.
FIDO U2F protocol
The FIDO alliance calls their authentication Second Factor Authentication. They say this is based on PKI (public key encryption) and is not susceptible to phishing. As with any PKI, signing up creates a key pair: a private key stored on the device and the public key sent to the U2F server. (It is a principal of cryptography that only the intended recipient of a message can read a message. The recipient uses the sender’s public key to encrypt responses that the sender uses to decrypt with their private key. The reverse is the case for going in the opposite direction).
Yubico sells YibuKeys. You plug those into a USB port on your laptop and you can attach it to a keychain. It supports the FIDO U2F protocol as does Facebook, Gmail, Google Cloud, Google Docs, GitHub, Dropbox, and Dashlane.
The way it works is when these websites prompt for a password, it then prompts for a code. You insert the Yubikey device and press a button which fills this information in.
Yubikeys says, ‘YubiKeys are more secure than Google Authenticator, Google Prompt, SMS, and emailed passcodes.’ Perhaps. They say their protocol is a step up from OTP because it is not subject to any kind of replay or phishing. It says it does this by saving a Key Handle into the target website. And the site identity can be tied to a specific web server key. Plus all of this runs as a browser plugin. So someone cannot punch in a code they stole from an SMS message and expect it to work on browser that does not belong to the legitimate owner.
Credit Card Companies
Some of these U2F devices are sold as multi-app, meaning they can support more than one function (Regular OTP devices like the Google Authenticator already support multiple web sites). To illustrate how this works, an Austrian Bank has issued a credit card that lets people both make purchases and login to their email. This is an NFC-equipped card too, so it can be used to make purchases with its digital wallet and an NFC check out terminal.
Mastercard and Visa too have used the FIDO standard to build dynamic CVV codes. This is mainly for contactless payment processing as well.
Someone reading this paper so far might wonder if the token fixes the problem with passwords then why not get rid of passwords completely? That is a good question. It is part of the vision for Fido. Plus it would eliminate a large part of hacking as it would force people to quit using passwords.
Others might be thinking that OTP and FIDO must have security problems too. But, most of the articles you see in the internet about OTP vulnerabilities are quite old and refer to using that with SMS text messages, which can be stolen from the air. The only HTOP vulnerability we see mentioned in the CVE database is this one from 2008. It seems to be saying that the server component can echo some its secrets to stdout.
And vendors promoting FIDO say that there is a risk from OTP attacks due to phishing and man-in-the-middle attacks. But if the hacker is attacking TOTP they would have to work quickly. And man-in-the-middle is not going to work with Gmail or your stockbroker. People set up MIM to send users to fake web sites that look like the real thing. You could not easily setup a listener between Gmail and a browser because when the hacker rewrites the data packets he or she would not have a legitimate certificate to do so. So the user would get a browser warning. And Gmail is not going to accept a stolen authenticator pass code over SSL either for the same reason.