User feedback for a bank authentication website included this comment:

It's annoying to get verification codes to my email or phone every time I log in to my Bank account from a new device

...and I'm looking at using implied trust to give the same assurance, but with less end user friction. In other words, I'm revisiting the User Experience of this approach.

What other options exist?

Edit: Implied trust is probably better described as transferred trust. Suppose I have a non cloneable hardware device. If that hardware device is involved in the authentication process, then there probably shouldn't be a need to have a "trust this computer" dialog.

The Bloomberg Authentication device, a smartcard, or others fit this description.

  • Can you give more information about the implied trust that you are considering? Perhaps a link or two? Dec 3 '15 at 16:47
  • @NeilSmithline added Dec 3 '15 at 16:52
  • Your suggestion of a new hardware device would not solve your problem. You would still have to authenticate the hardware device the first time you connect, just like any other device.
    – TTT
    Dec 3 '15 at 19:13
  • Reading this, the comments, and the answers, I'm still a little confused about what's going on here. Your current setup is that a when a user tries to log-in from an unrecognized device he or she has to use a security code delivered by email/sms/whatever. After the user supplies the code successfully, you do the checkbox thing to enable trusting that device as a substitute for entering a security code every time they log-in from it, right? Or are you thinking about moving to allowing device-trust vs. currently making them do a code on every login? Or are you allowing device-trust already ... Dec 4 '15 at 4:00
  • 1
    @LamonteCristo Ahh, I see. You're sort of clean-sheeting it (ie. asking what possible mechanisms would be better than what you have for your situation, without necessarily absolutely requiring any compatibility with any two-factor auth elements you already have in place) Dec 4 '15 at 18:16

There are obviously alternatives to making the second factor of two-factor authentication be the user logging in from a trusted device. There are also certainly alternatives to authenticating that a certain device is in the control of that user before it's registered as a "trusted" login device for that user besides the security code method. *The hard question is whether there are any of either methods that are clearly, unambiguously better in terms of usability, across your whole population of users. While also filling the heightened level of security needed for a banking site

To be honest, I kind of doubt it.

Let's illustrate by example:

Some alternative methods of 2FA to authenticating a user robustly on first login from a specific device/machine then considering it as "trusted" for logins thereafter:

  • One-time PIN authentication token:
    Doesn't require the user to have a network-connected phone or PC to, say, get a security code. Does require the user to physically carry around the token wherever they might want to access their account. (Also requires bank to distribute them. Probably wouldn't make financial sense to do just for users only to get a code the first time per device they wanted to use, assuming you did want to keep the trusted-device scheme. But, OTOH, if you wanted to go for a more secure arrangement where users need a code at each login it might.)

  • USB 2FA device of some sort:
    May not require user to fool around entering codes & such, but obviously requires users to physically carry around, just like a token. Plus, may only be able to use to log-in from machines/devices with a full USB port.

  • Making user get a security code via an SMS or authenticator phone app:
    Doesn't depend on what device user logs-in from, but obviously is dependent on user having their phone with them. Essentially what you're doing now to authenticate before adding a new device as trusted, except that you would be making the user get a code from his/her phone for every login.

  • Making user get a security code sent via email:
    Would allow user to log-in from any machine/device where he/she could access their email. Would also require each user to get a code for each login, plus go through hassle of logging-in to a separate account/service and then logging-in to yours. (Not even mentioning security implications/drawbacks, of course.)

  • Checking whether the user is logged-in to another service that you trust the authentication security of:
    Lots of services nowadays make use federated identity from a larger, 3rd party-service, of course. So far, they've typically been used as a sole authentication factor by services that don't require particularly strong security (like blog commenting) and don't want the hassle of setting up an authentication scheme themselves. But there's no technical reason (that I know of) that you can't use it as a second factor. This might avoid user impatience with an extra-authentication factor when a user is logging-in from any device where he/she is typically logged-in to the other service. But where they aren't, users might be as or more irritated by needing to log-in to another service as they would be using a security code.

  • Smartcard:
    Deploy a USB portable smartcard reader and smartcard to each user. Would, of course, require user to have both whenever & whereever he/she wanted to login.

(-Doable-but-not-considered: Using facial recognition as a biometric second factor from any device with a commodity camera. Flexible, but laughably insecure. Maybe if/when more devices will be packing RealSense or similar camera hardware... )

I'm sure you get my point. If there were an obviously more usable, practical-to-deploy, and at-least-as-secure* method of doing the second factor of 2FA out there right now as the security code---> trusted device way it would probably be well-known and in very wide use. Instead, that model has fallen into a role as a semi-defacto standard among the biggest services on the net that use 2FA. I think that's largely because asking somebody to take a few moments to use a security code the first time they log-in from a device (and perhaps make a few especially sensitive actions within the service) is a pretty minor imposition.

The occasional grumpy user with zero care about the security of their banking service notwithstanding. :)

Oh, about the checkbox to giving the user the chance to decide whether a device should be deemed "trusted", while it is an extra thing that some users will puzzle over and the mental attention needed to choice that inspire a little bit of that feeling of friction, many users even today still log-in to their banking sites from devices they share or don't otherwise control. Even, yes, from publically-shared computers. [Sigh.] That's something that at least deserves serious consideration when thinking about whether to have the checkbox and, if so, what the default state of it should be. (As many, if not most, users will just leave whatever the default check or non-check is alone.)

*Personally, I'm not a huge fan of the device-trust mechanism in something like a banking-site role. There are some potential issues with it that make it an arguably less-secure mechanism than requiring an SMS or authenticator app code. But I understand that, in the real world, sometimes one has to trade a little security for a larger improvement to User Experience.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.