A trusted device still goes through 2FA

Question

Some of users have trusted a device, yet they're still required to go through two-factor authentication. (Well, sometimes, but not always.) What gives?

Answer

To answer that, let's start by defining a "trusted device." A trusted device means that, under the right circumstances, you get to bypass 2FA. If one, or maybe a handful of users, are having to undergo the two-factor process even though they previously trusted a device, that typically means one of four things:

• They aren’t logging on from a trusted device after all.
• The user managed to “untrust” their device.
• The user’s device wasn’t “permanently” trusted.
• The trusted device TTL value has expired.

Thing No. 1 – they aren’t logging on from a trusted device after all – is something that, admittedly, can be a little confusing. That’s because we tend to think of devices as being a piece of hardware (like a computer or a cellphone), and when we trust a device it’s natural to think that we’re trusting that piece of hardware. For example, we trust our laptop computer and then, the next time we log on, we have to go through 2FA (and we’re given to the option to Trust this device for future logins). But didn’t we already trust this laptop computer?!?

Believe it or not, no, we didn’t. (Or at least not necessarily.) That’s because the hardware is only a piece of the trusted device puzzle. As it is, a Hosted Login device consists of:

• A specific piece of hardware (like a laptop computer).
• A specific web browser (like Chrome).
• A specific user (like karim.nafir@mail.com).

In other words, suppose Karim logs on to your site using his laptop computer and the Chrome browser, and then trusts this device. What Karim has actually trusted is the combination of:

• That specific laptop computer.
• The Chrome web browser.
• The user karim.nafir@mail.com.

If any of those three factors change, then Hosted Login believes it’s dealing with a new device. That means that if Karim logs on using the same email address and the same computer but a different web browser (e.g., Firefox) then he’s effectively using a new device and has to go through 2FA all over again:

To avoid 2FA the next time he logs on, Karim has to trust this new device as well. (Yes, a single piece of hardware can host more than one device.) And if he logs on a third time using, say, Safari or Edge? Well, that’s another new device. And if he logs on from his cellphone? Yet another new device. And, as you might expect, if Toni Ng borrows Ken’s computer and logs on using the Chrome browser, she’ll have to go through 2FA. That’s because the unique combination of laptop computer, Chrome web browser, and the email address toni.luc.ng@gmail.com has never been trusted.

To make a long story short: if a user is unexpectedly asked to go through 2FA, the first thing you should do is verify that the user is using the same device (as Hosted Login defines a device). If the user is, say, logging on from a different web browser, well, that could be the “problem” right there.

📘

Is there any way for a user to determine, in advance, whether a device is trusted or not? No; this kind of information isn’t stored in a way that’s accessible to users, (or to administrators, for that matter).

But wait: there’s more. In fact, there’s a fourth factor that enters into our trusted device equation, and that fourth factor (cookies) explains Things 2 (the user “untrusted” their device) and 3 (the user’s device wasn’t “permanently” trusted). When you trust a device, one of the things Hosted Login does is write a cookie to your web browser. This helps explain why different web browsers result in different devices: a cookie written to the Chrome browser can’t be accessed from the Firefox browser. 

So why does a cookie cause a user to go through two-factor authentication? Well, the cookie itself doesn’t do it, but the absence of the cookie does. If a user deletes their cookies (either all their cookies, or just the cookies associated with your login page), that also deletes their trusted device cookie. And by deleting that cookie they have effectively “untrusted” their device. Which means that, the next time they log on, Hosted Login won’t recognize the device as being trusted, and makes the user go through two-factor authentication.

A similar thing happens if you log on to a website in incognito (private) mode and trust your device. If you do that, a cookie is written to your browser and, while your browser session is active, your device will be trusted. However, if you’re in incognito mode and you close your browser session, then all your cookies are automatically deleted. As a result, your device is no longer trusted.

That, at long last, brings us to perhaps the likeliest-culprit in our scenario: the trusted device time-to-live value (TTL) has expired. Users can bypass 2FA as long as they’re logging on from a trusted device and the t TTL hasn’t expired. If that time-to-live value has expired then users will have to go through 2FA and retrust their device.

For example, suppose you’ve configured the trusted device TTL to be one day (24 hours). Karim logs in on Monday morning and trusts his device. He logs on again Monday afternoon, and he bypasses 2FA; that’s because the TTL value is still valid. Then he doesn’t log on again until Thursday. At this point he’ll need to go through TTL and retrust his device. That’s because his 24-hour “grace period” has expired.