What I understand about two-factor/multi-factor authentication (in 2023)

September 6, 2023

I am broadly a MFA (Multi-Factor Authentication) skeptic (cf) and as a result I don't have much exposure to it. For reasons beyond the scope of this entry, I've recently been needing to understand more than usual about how it works from the perspective of people using it, so here is my current understanding of your generally available non-hardware options that can be used in a desktop environment (security keys are out of scope).

There are three generally available and used approaches to MFA at the moment: SMS, time-based one time passwords (TOTP), and what I've heard called 'push-based approval' using smartphone apps. Of these, I believe that TOTP is the most popular, and a place that simply talks about 'MFA' is probably talking about TOTP MFA authentication, especially if they say they support multiple smartphone apps.

(At some point this list may include WebAuthn, but right now you mostly need a hardware security key to use it on your desktop or laptop.)

In SMS MFA, the place you're trying to log in to sends a SMS message to your phone number with a code that you have to enter (sometimes you can also get the code emailed to you). Websites vary on whether you can enroll more than one phone number for these messages. SMS MFA is considered insecure, partly because it's generally not that difficult to get someone's number 'ported' to a new device under your control, at which point you get their SMS messages. On the other hand, SMS is easy for people to start using, because practically everyone can already receive text messages.

In push-based approval, a special app on your phone gets push notifications of pending logins and asks you whether or not you approve them. With some hand waving, this is pretty secure, as it requires possession of your phone in an unlocked state and perhaps unlocking the app itself. An attacker can't step into the middle to impersonate your phone (or the app on it) the way they can with SMS and ported numbers. Again, websites and companies vary on whether you can enroll multiple devices for push based approvals. One current drawback of push based approvals is that there is no standard protocol for this, so each provider of this service has their own custom app (and, of course, you have to trust their app to not be scraping your phone for every bit of marketable information it can extract).

The third option is TOTP. In TOTP the website and you share a common secret code (often provided as a QR code) and you use a standard public algorithm to combine this secret with the current time to generate a numeric code. If you give the server the right code, the server 'knows' that you know the shared secret at this time (well, within a time window). Unlike push based approvals, there's no explicit communication between any server and the TOTP app on your phone; the app is a standalone, isolated thing. Because the algorithm is standard and public, it's been implemented by many different smartphone apps and those apps aren't tied to the website or provider they're from; any proper TOTP app can do TOTP with any proper TOTP website (or other server).

Looked at from a suitable angle, TOTP is really a second password (the shared secret) with a weird way of proving to the server that you know this password. It is 'Multi-Factor Authentication' partly because you're normally supposed to use another device to generate the TOTP code, not your desktop or laptop, and partly because you don't memorize the TOTP secret, you store it somewhere. If you're logging in on your smartphone in the first place, TOTP's MFAness boils down to 'your physical phone is what knows the TOTP secret, not you', so only someone in possession of your phone (in an unlocked state) can get at it.

TOTP is a popular way of doing MFA, perhaps the most popular right now, and it's not hard to see why. It's more secure than SMS and doesn't require the website to find (and pay) a SMS provider, and while it's probably less secure than push based approval, it doesn't require a bespoke mobile application along with a push notification backend cloud server setup. There are plenty of client applications for people with smartphones to chose and as I understand it, the server support is relatively widely available in open source libraries.

(There are some TOTP desktop applications, but I think your choices aren't as broad or as polished as on phones. On the other hand, you can get them even on Linux.)

Websites using TOTP MFA may allow you to enroll multiple devices, each with their own TOTP secret code. However, even if they don't explicitly offer this option, there is nothing stopping you from loading the same TOTP secret code into multiple TOTP apps on multiple devices, or even directly saving the TOTP secret code so that you can later feed it into whatever you want. Websites often ask you not to do this (and especially tell you to throw away the initial TOTP secret code or QR code, not keep it anywhere people can find it), but they can't force you and they can't tell if you're doing this because there's no explicit communication between them and your TOTP app the way there is with push based approval.

(The advantage of enrolling multiple devices with separate TOTP secret codes is that you can hopefully revoke just one device's TOTP secret code if something goes wrong. If everyone has the same code, everyone has a flag day if it has to be revoked and redone. You might also get better auditing.)

This means that if for some reason you have to add MFA to a shared administrative account on some website, you're generally best off if the website supports TOTP MFA authentication. You can probably get TOTP clients for any environment the relevant people use and load the TOTP secret code into all of them, enabling each person to MFA to the website as the shared account. You can probably even print out the QR code the website generates for you, fold it up, and seal it in a 'break glass in case of emergency' envelope in your password safe.

(Each TOTP app knows the TOTP secret code that's encoded in the original QR code, but they may well not support any way of giving it back to you, especially in usable form, partly because that's a security exposure.)


Comments on this page:

From 193.219.181.219 at 2023-09-07 00:42:32:

(At some point this list may include WebAuthn, but right now you mostly need a hardware security key to use it on your desktop or laptop.)

Windows has long had a software-based WebAuthn/FIDO2 token aka "platform Authenticator" as part of the OS, branded Windows Hello (no, not TPM-based, that's only used by Windows Hello for Business which is of course completely unrelated). I believe macOS now has one as well, as does Android – the main focus of the new "passkeys" trend is these OS-integrated authenticators (plus ways to get them from one device to another, such as Bluetooth).

Linux is the only outlier, with a few projects that emulate FIDO tokens (e.g. via uinput or uhid) but none of them really catching on, though it seems there is an "xdg-credentials-portal" that aims to finally change that.

I'm increasingly seeing non-technical sites abandon passwords and switch to SMS authentication only. Technically it requires me knowing my email address and having my phone, but it feels more single factor than multi factor.

I've run into this with either Hotels dot com or Booking dot com this August, and there were others

«abandon passwords and switch to SMS authentication only. Technically it requires me knowing my email address and having my phone, but it feels more single factor than multi factor.</i>»

That I guess is "multi-step" rather than "multi factor". Also it does really matter whether one uses the same factor (whether "known" or "had") or not, what matters is whether the security token are independent.

http://www.sabi.co.uk/blog/20-two.html?201107#201107

Also using mobile phone SIMs for the first or second secrets is very inconvenient because losing the SIM locks you out of a lot of places. Always use multiple phone numbers and/or multiple e-mail addresses and/or multiple FIDO etc.

By Ben Hutchings at 2023-09-28 22:44:30:

All of those three are vulnerable to phishing:

  • With SMS and TOTP, the one-time code can be phished along with their password
  • With push-based approval, it's not even possible for the user to tell how the request was generated

I tend to think push-based approval is the least secure of the three. I've read several incident reports where the attacker got a user's password and then repeatedly tried to log in, spamming them with approval requests until they gave in and tapped Approve.

WebAuthn should be secure against phishing since the browser takes care of comparing web site identities. The need for a hardware token has been a major barrier to its use, but maybe passkeys will change that.

Written on 06 September 2023.
« Having ClamAV reject email using the Malwarepatrol database seems unwise
(Unix) Directory traversal and symbolic links »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Sep 6 22:56:22 2023
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.