3

Inspired by a discussion elsewhere, I've been wondering if the concept of a "trusted device" is considered a factor - on it's own - in multi-factor authentication?

Given context is that a mobile application has signed on to a service that requires authentication. The service will, after login, trust the device from this point. The mobile application can now use the device's own authentication methods (pin-code, password, fingerprint, face recognition) to authenticate the use of the app.

Would the combination of "trusted device" and e.g. fingerprint be recognized as a multi-factor authentication?

Improve this question
5
  • 1
    "The mobile application can now use the device's own authentication methods for accessing the device" -- this phrase makes no sense to me. What do you mean? Do you mean the app can use the device's authentication methods to access the app?
    – schroeder ♦
    Mar 24, 2022 at 9:21
  • Why is it important that the trusted device be "considered" an authentication factor? If you are happy with it, why does someone else need to be? The answer to that is likely to influence the answer to your question.
    – schroeder ♦
    Mar 24, 2022 at 9:23
  • @schroeder The phrase should signify that when opening the app, you can use your device's unlocking feature as login in the app. The "importance" is not relevant for my question. My question is related to what is consensus and "best practices", not individual perspective.
    – Repox
    Mar 24, 2022 at 10:49
  • I edited the phrase to make it clearer.
    – schroeder ♦
    Mar 24, 2022 at 12:09
  • "Importance" is relevant if you need to convince stakeholders or 3rd parties, which is why I asked. As the app developer, you define what constitutes a "trusted device", and why and how you trust it (and what you are authenticating). Is the process you describe enough to reduce risks as you have defined them in this risk context? That's the only important part. It doesn't matter if some consensus somewhere might technically define it as a particular category.
    – schroeder ♦
    Mar 24, 2022 at 12:12

2 Answers 2

Reset to default
3

Yes, a trusted device is a possible additional authentication factor. The strength of the protection depends on how it is implemented. Ideally you would have a hardware protected machine bound certificate (like in a TPM). But also cookies, deviceid or non-protected client certificates could be used to implement this.

In the scenario where it is only weakly protected it is still an effective mean against some attacks. But it’s also for the convenience of the user: if the device was seen before, other additional checks might not be needed.

The trend to trusted devices comes from things like Zero Trust architectures (which is funny enough), endpoint security and SASE, Cloud First or registered devices for cloud applications (like Azure Active Directory where you can register your personal devices to an organisational tenant).

With new passwordless authenticators the protocols typically rely on authenticating the device because the device protects the credentials.

Improve this answer
2

"Something you have" can include the device that the app is running on if the authentication is done on a separate system (the server). But you have to determine what you are "trusting" as the authentication factor.

  • the device ID or other device-generated data that is exposed to the user
  • a certificate or a stored secret sent by the authentication system and protected against copying

The strength of the trust and the appropriate level of trust involved will depend on the risk assessment that you have performed.

But, as you can see, it's not the device that is being used as an authentication factor, but the data from the device that is being authenticated. Once you adjust your focus to that reality, things can get clearer for you.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .