Overview
I’ve recently upgraded my environment with the latest generation of Yubikeys, the Yubikey 5. While the previous generation is still functional, I wanted to phase out my 2048-bit limitation on the Yubikey Neo. I’ll also be playing with Password-less login, but that will be discussed in a future article.
For now the focus will be on how Two-Factor Authentication is implemented, where it is going and why a lot of implementations fail to understand what Two-Factor Authentication is trying to solve.
The Factors
There are five factors of authentication.
Something you know.
This is usually a password, passphrase or pin-code.Something you have.
Something physically accessible. Often an app on a phone, authentication device or CCID. In our case it is a Yubikey.Something you are.
The most common implementation of this would be biometrics.Somewhere you are.
An implementation of GEO-fencing, which is the restriction of connections based on location. Rarely implemented beyond a basic country IP white or black-list. However if done properly it can restrict logins to a specific district or even a specific building.Something you do.
Often seen as an extension to something you know, it is an action that must be performed.
Commonly used for smartphone lock-screens, instead of providing a pin the user swipes a specific pattern.
Using a single factor is considered ‘Single-Factor Authentication’, whereas using a combination of the above is considered ‘Multi-Factor Authentication’. The striving point is offering Two-Factor Authentications via an open and audited standard. For most of this article I’ll refer to Two-Factor Authentication as 2FA, current implementations will result in me only referring to the ‘Something you know’ and ‘Something you have’ factors from here on out.
According to the 2017 FIDO Authentication report, approximately 55% of user facing products provide a form of 2FA, but only 5% of this group provides a solution that is based on public-key cryptography. This leaves 45% offering weak authentication. In reality, only a small percentage of the average user base utilizes 2FA without being incentivized in some manner or form. There are extremely few services that implement 2FA to its full potential, let alone provide three or more factors of authentication.
The Technologies
One of the oldest and most common approaches to Two-Factor Authentication are OTPs. This term stands for One-Time Password. There are two common implementations of OTP via OATH, named TOTP and HOTP.
TOTP
TOTP stands for Time-based One-Time Password.
The core principle is that it provides the user a code, which is derived from hashing the secret key together with a timestamp. This results in a code that is ‘syncronized’ to current time.HOTP
HOTP stands for HMAC-based One-Time Password.
Identical to TOTP, except that it doesn’t use time, but instead utilizes a counter. The benefit is that codes are viable for a long time, but poor implementation can result in counter-desynchonization.
Early implementations relied on SMS and Email to distribute an OTP to users. While these methods are considered some of the least intrusive methods in regards to user convenience, they are also undeniably insecure as Email and SMS are considered to be insecure. Emails and SMS should be considered public communication, unless secondary security protocols have been put into place, as all communication happens over clear text.
Software OTP surfaced to replace SMS and Email-based OTPs and provide a faster and more secure alternative. This solution is based on the OATH framework.
A website offering this solution would provide a shared secret key (often provided via QR code, for quick insertion), the software would scan it, store the secret key and generate a TOTP code every refresh.
The default TOTP implementation operates on a shared-secret-key principle and generates a six digit SHA-1 HASH for every 30 second interval between a secret key + time-stamp. It should be noted that on average, due to compatibility with latency and time de-synchronization, these codes are often valid for several minutes beyond the 30 second time-slot.
The most common implementation of Software OTP is via the Google Authenticator for Smartphones. It can be found on the Google Play Store and the IOS App Store. For desktop there are several solutions, from integration with password vaults to software like WinAuth, which is effectively Google Authenticator for Windows. It should be noted that their popularity is significantly less than their respective mobile implementations.
I should also make a mention of Google Prompt. and DUO., as they are similar solutions with less user interaction. Google prompt will send your phone a push notification which will allow you to approve the request with a simple yes or no, whereas DUO does the same but in app form. However both are proprietary implementations and have limited availability.
All these implementations aren’t ideal as they often don’t even meet the criteria to qualify as a second factor. Especially in the case where verification is done via the same device as to where the access request is coming from. There is also the problem that a lot of these solutions are prone to system vulnerabilities, which a dedicated security device would have a much lower likelihood of being affected by, provided proper auditing is in place.
Practically speaking, they are major improvements over the SMS and Email-based OTP codes and they will be more than sufficient for your average threat-model, but they are not ideal.
So what else do we have?
Dedicated Security Devices.
A cryptographic device dedicated to handling secret keys independently of the system. This allows secret keys to be properly secured and isolated, while still providing the desired output. They are often referred to as Security keys, Smart-Cards, CCIDs, FIDO keys et cetera. There are a lot of these little things, as technically speaking, even the two decade old RFID badges that are still used in building security today still qualify.
The scope will be limited to Yubikeys only, as they are quite the ambitious little things. Most security keys adhere to the FIDO Alliance standards and protocols which were in part developed by Yubico. They cover most of the technology that a Dedicated Security Device can offer, offer open source libraries and adhere to the standards available. The result is that nearly any implementation of 2FA, save for SMS or Email-based OTP, can be replaced with a Yubikey.
While there is a lot more to these devices, for now I’ll limit the scope of this article to their OATH and U2F functionality.
OATH
The Yubikey OATH implementation is relatively simple, instead of storing the Secret keys on the device you desire, they are now stored on the Yubikey.
Just like its software counterpart, it is able to support both HOTP and TOTP codes. Those codes can be retrieved via an accompanying app of preference on the platform of choice. This implementation guarantees true 2FA, as only the key itself will be able to generate the codes.
U2F
Also known as Universal Two-Factor authentication. Where as OATH is more broadly available, it is much more efficient to use U2F when it is available.
U2F allows the server to send a challenge to the security key, which (in the case of a Yubikey, after touching it) provides a response back to the server. When the key is registered to an account, it generates a specific a private and public key, it shares the public key with the server.
When authenticating with the Security key, the server will issue a challenge, the security device will then sign this challenge with the private key specifically created for this service, it then sends back the signed challenge which is then verified by the server with the registered public key. This is of course a gross simplification, as there are significantly more mechanisms in place to prevent incidents like MitM-attacks, device cloning and much more, I recommend the following article if you want more information on how this works.
The result is a faster, more robust and significantly more user-friendly implementation of 2FA compared to OATH.
Notable flaws
As with anything, there are a couple of inconveniences and flaws often associated with 2FA, and when writing about a subject, it is only ethical to include both the positives and negatives.
- User inconvenience
This is by far the biggest hurdle to any new technology, especially security oriented ones. This problem isn’t inherently limited to 2FA either, any change to a user’s routine is prone to this. There is a lot that can be said on this subject and the ethics of forcing change versus giving the user control, but that is a rabbit hole that deserves its own article. For now I’ll just state that a large part of this is resolved by educating users to the risks and making solutions as user friendly and accessible as possible.
I don’t expect Security Devices to ever become a requirement for users, but solutions that compromise on security to increase user convenience should also be phased out.
I’m looking at you, SMS and Email-based OTP. - Factor Recovery
This is one of the biggest reasons 2FA implementations fail so miserably. What happens when a user loses access to their 2FA device or application? Do you tell the user Tough luck or do you allow them to simply turn it off via an email recovery link? Unfortunately, it is more often than not the latter.
Best practices would indicate that when registering a second factor for security purposes, there should be a requirement for a third factor, which should equal in strength to the second factor. Ideally this would be implemented in such a manner that the user can use either factor whenever. An example would be that to register a security key, the user must also register secondary key or configure OATH. It mostly comes down to the threat-model, but security is only as strong as the fallback solution.
In the case that a user loses both of these factors, lock-out should be enforced for the higher level threat-models. - Availability
Many websites today still do not offer any 2FA, even when they do it might still be limited to SMS or Email-based OTPs. Even in the case of OATH implementations, which fortunately is increasing, technologies like U2F remain unavailable. U2F is currently implemented on very few platforms, even though this technology was released in 2014, with browser support being implemented in 2015.
Implementations
I’ll highlight a couple of websites and discuss their implementations. It should be noted that the threat-model of a web-shop should vary from that of a financial institution, yet neither ought to be inherently insecure.
Amazon
While Amazon allows you to register an OATH application, it utterly fails at the implementation of this, as the only time I’ve ever been prompted to input an OATH code was when I was trying to access my OATH settings. Logging in only requires a password.
It should also be noted that when Amazon detects a user logging in from an unknown IP, it will disable the user’s password without telling them, occasionally it’ll ask for a verification code, but other times it’ll simply state that the account password is wrong.
They will then send an Email-based OTP to the user, which becomes their temporary password. Note that this also bypassed 2FA, just like the password does. Not only do they disable the second factor, but they also use an easily reproducible and insecure method to log you in. Using this approach, any amazon account is always at risk.
Gitlab
Ah Gitlab,
one of the very few websites to allow a user to register a security key via the U2F protocol. Reliable backup methods via OATH or secondary security keys, no password limitations and overall good practices. This is how it should be done, websites take note.
As per usual, Google has attempted to do something well, but yet again have managed to come up with a solution that is utterly devoid of reason.
OATH and U2F are supported, but U2F registration is limited to a proprietary Google library, only available on Google Chrome. Somehow, Google has found a way to make an open source protocol and implement it in a proprietary manner. I’m not exactly certain how they’ve accomplished this, but here we are.
If you register a security key via Google Chrome, it can be used to log in via other browsers, but the registration itself is only possible via Google Chrome.
2FA can be bypassed via recovery, but Google offers a solution, which is the ‘Advanced Security’ option, which requires the registration of two security keys minimum. For some reason this does seems to unlink all associated security keys.
‘Advanced Security’ does a couple of things, most importantly it locks the available recovery methods to Security Keys and locks down the total account access a bit more. This does come at the unfortunate side effect of disabling the app-password feature. It should also be noted that Google mentions being able to unlock accounts with ‘Advanced Security’ configured via costumer support, so social engineering remains a problem.
Paypal
I was initially trying to showcase a bank, but those practices vary heavily from country to country, due to different regulations and an unquantifiable amount of proprietary 3rd-party devices,
an entirely different rabbit hole.
The login portal for Paypal is quite standard, unfortunately their only 2FA implementation is via SMS-based OTP generation, there is an alternative proprietary carrier take on SMS-OTP which has limited availability, but this seems to be more of the same. Password and Email recovery is relatively straight forward, though 2FA recovery does seem to be somewhat secure. I must admit that a financial institution utilizing a known unreliable security factor is quite disappointing. That said, this is also the company that limits passwords to a maximum of 20 characters and still employs recovery questions. Why is it always the companies with the most important data that seem to actively go out of their way to avoid adhering to best practices?
I’ll also note that Paypal allows email address-based validity checking, meaning any provided email address will be checked against all active accounts to find a potential match.
Conclusion
Two-Factor Authentication prevents compromised factors from endangering account security. While the technology itself is relatively old, we’re only getting around to proper implementation now. In order to align with user interests, the lowest security settings should align with the minimum threat-model, while there should be additional options for the user to utilize better security practices.
Just as with best password practices, users should not be limited or inconvenienced even more if they opt for a higher level threat-model. Better implementation of more robust threat-models should be encouraged to allow for higher adoption rates, as convenience has become a larger focus of security practices in general.
Sources
FIDO Alliance 2017 Report on Authentication
Yubico U2F Documentation
Yubico U2F Protocol Documentation
Yubico OATH Documentation
Google’s Advanced Security Documentation