In case you missed it, passwords suck. No really. https://blogs.serioustek.net/post/2019/10/23/ncsam-post-0010-lets-talk-about-passwords
That being the case, one of the best ways to improve security is to use multi-factor authentication.
If you are not using multi-factor authentication (or don’t know what it is), stop reading this article RIGHT NOW and turn it on for any service that you can (or go read this NIST paper: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf ). Many web services like banking or healthcare should already have the option to enable an additional factor of authentication – some even require it, and this is a good thing.
But why? This is just a simple step that gets around the being human problem when it comes to proving to computers that we are who we say we are. So in the event that we do re-use a password or our credentials are stolen, MFA will stop an attacker from gaining access as they will likely not have your MFA token.
Authentication “factors” are things that you are already familiar with: something you know (your username and password), something you have physically (like an RSA token, Google Authenticator on your phone) and something you are or do (like biometrics, or approving an app request on your phone). There are TONS of different solutions, but for the most part they all effectively fall into one of these categories.
A common factor used by web services is to send a “one time use” code via SMS text or email. While this does add some extra security, it is not the most secure (more on that later) and the user experience isn’t great – you have to wait for the message to arrive, switching apps on your phone isn’t easy with copy\paste, and you have to do all of this EVERY TIME you login.
Not all MFA Solutions are Created Equal
There are several options when it comes to adding another authentication factor to a login, but you need to be aware that they do not all provide the same level of risk mitigation. Here are the most common factors in use and why you should or should not use them:
|Username\Password||BAD||Yes, but why?|
|SMS, Phone||Less bad (but still bad)||SIM card hacking is easy|
|OTP||Less bad (depends)||SMS\Phone\Email (see above)|
|TOTP||Pretty Good||Still vuln to replay, phishing; just a PSK|
|App Push||Good||Replay attack requires social engineer|
|SmartCard||Moar Gooder||PIN unlock, use CRL; Complex deploy|
|FIDO2||Most Gooder||BIO or PIN; Strong Authentication|
OTP and TOTP are similar in that they are both short (usually 4 or 6 characters long) strings – but the subtle difference being that the ‘T’ in TOTP means that every 30 seconds or so, the code will change. OTP on the other hand, is a system-generated code that is then sent to the user via a different channel, other than the actual service itself.
SMS and Phone
While this may be a very common authentication factor deployed today, it is by no means the most secure. SMS messages and phone calls are used to send one time passcodes to the be used for validation. But, it is not the phone that is the actual factor – but rather the SIM card (or phone number) that is being used to send the code to. Unfortunately, it is VERY easy for someone to steal or clone a SIM card, then they would simply receive the one-time-use passcode and this multi-factor authentication method is all but defeated. Here’s a very recent example: https://www.theverge.com/2019/8/31/20841448/jack-dorsey-twitter-hacked-account-sim-swapping
Time-based One Time Passcode (TOTP)
TOTP as a factor is a bit more secure because it doesn’t rely on the same SMS\Phone\SIM technology as others; it also tends to be a good bit more user friendly since there is usually a hardware token the user has or an app that can be easily used. Unfortunately, TOTP is not as common outside of the enterprise.
But even this is not perfect as it is still possible to get unsuspecting users to “login” to sites that look like the real site, but are actually malicious – this is known as a replay attack. When the user logs in to the malicious site (with the username\password\TOTP token) the attacker immediately turns around and uses those real credentials to (‘replay’) login as the victim.
Alternatively, an attacker using social engineering, can simply call a user and obtain the TOTP token code – he then has 30 seconds (give or take) to login as the victim.
The App Push factor is similar to OTP via SMS\SIM except that it typically relies on modern software to securely communicate with the server and confirm with the user that he or she really wants to log on. That said, this method is still vulnerable to social engineering, similar to the other factors – user training and knowledge is key to ensuring less risk.
This may also be known by other names – including Client Certificate authentication or PIV\CAC in US DoD environments. This form of authentication is quite secure – it requires both a physical card (thus the name ‘smartcard’) with a chip containing a client or user certificate. The chip requires a PIN to unlock and is built to self-destruct if physically tampered with. If the card is lost, a certificate revocation list can be employed to ensure it cannot be used in the wrong hands, thus forcing a new smartcard with new client certificate to be minted.
The problem with smartcards is that the environments are VERY complex to deploy and maintain and require significant administrative involvement; this makes them unfeasible to use for public sites or services.
FIDO2 is the latest set of specifications from the fido alliance – the industry’s answer to the global password problem and addresses the numerous issues with current authentication mechanisms. It is build with end-to-end security, even able to prevent replay attacks. There is a great deal of information at on the FIDO Alliance site here: https://fidoalliance.org/fido2/
Any MFA is better than no MFA as it lowers risk and increases difficulty for malicious actions or account takeovers. User training and education playing a very important role in further reducing risk. The trade-off for security is usually user experience, so it is important to choose the right MFA scheme. User context can aid in improving the experience, but the key thing to remember is that traditional usernames and passwords simply do not provide good security.