With the explosion of password leaks, and the growth of cheap and fast processing power, there's a good chance you're at risk of identity theft. Can you trust that the person logging in to your systems is who they say they are? If you run a site with sensitive data or controls, do you trust that your users have strong passwords and change them routinely? Username and password-only authentication is no longer safe for sensitive data; you need to employ additional factors to strengthen your system's security.

A password operates on the principle that the user should be the only one to know it, thus a username and password combination, when correct, indicates that the person is who they say they are. But when passwords are brute-forced (iterating over password combinations till accepted) or stolen, your system and site are at greater risk. While a complex password is harder to brute-force than a weak one, additional forms of identity verification are better than pushing exaggerated complexity onto one method alone.

"Something you know," "Something you have," "Something you are"

The most popular authentication technique on the web is when a person supplies their username and password. However, a password is only one method for establishing identity, there are two additional categories to consider. A person can also be identified by who they are (properties inherent to them) or by what they do. When you see someone enter the room, you might recognize them by their face or by their speech. Facial properties and speech characteristics are inherent to individuals. A third category for identification is trusting that a person is in possession of something. When you receive a phone call the caller is identified by at least their number. If you recognize the number you trust that the person on the other end is who you expect them to be because they are calling from a known number. The categories "something you know," "something you have," and "something you are" can be thought of as knowledge, ownership, and inherence authentication factors, respectively.

Let's think about a phone call once more. The caller is identified by their number (which is often associated with a name and photo) but it is further confirmed by the sound of the person's voice. In this example two factors were used for identity verification; ownership of the number, and inherence of the familiar audio properties.

Trust in identity accuracy is increased when a system correctly employs multiple factors of authentication. For systems in place around sensitive data, multiple factors and particularly strong techniques increase the security of the system.

On the web, inherence authentication techniques are less common, or not recommended, for many reasons. Biometric qualities like fingerprints or the sound of a voice are limited to specialty devices and have technical restrictions for broad use. Inherence techniques that rely on the user's system agent, like computer identification (e.g. IP address) or behavioral (e.g. browser referrer) are easily prone to spoofing and are not recommended.

We've already seen a phone as an example of an ownership factor but with the increasingly high adoption rates they've become a popular tool for use in two-factor authentication systems. By nature, mobile phones are often unique to — and within arms-reach of — each owner, so they are more prevalent than many inherence factors like biometrics.

Identity verification with mobile phones can be accomplished in many ways. One popular method is the exchange of one-time-use tokens. Much like a system stores account details like username and hashed password, a user's phone number is stored upon account setup and, during authentication, the phone is dialed or sent an SMS containing that unique token. The authenticating user must enter the token into the system and, upon confirmation, access can be granted.

Drupal Modules

Fortunately for Drupal, two-factor authentication solutions are provided by stable, contributed modules such as Duo and TFA. (Full disclosure: I am the maintainer of the TFA module.) These modules hook into Drupal's standard user authentication process to send and validate a one-time-use token as a second step after username and password validation.

The use of one-time tokens is not new in Drupal; think of the password reminder functionality that's built into Drupal core. When you can't remember your password Drupal can send you a login link so you can reset it. Drupal generates a one-time-use token and emails it to you as a link. When you click that link it verifies your identity and successfully authenticates your account.

"Man-in-the-middle"

It's important to realize the additional layer of security used by mobile phone two-factor authentication; that the transmission of a one-time token happens over a completely separate connection layer than that of the website. This can help mitigate a "man-in-the-middle" attack where a malicious entity is monitoring communications with the system. The attacker would need to monitor the phone's connection to its service provider as well as the network connection of the computer — assuming the password wasn't previously stolen and the same device is not in use for both, of course. When you retrieve a one-time token over e-mail, it is almost assuredly taking place over the same connection layer as your browser.

The internet is a risky place and you put your site at even more risk when you control access to sensitive data with only a standard username and password combination. While complex passwords are important, you're better served by adding additional authentication factors such as one-time-use tokens over mobile SMS. The separate communication layer, and physical ownership properties, allow for greater trust in identity verification — and is recommended for maintaining a strong and healthy security posture.