Webauthn: Clarify how a user can authenticate from multiple devices

[cjthompson]

The current draft specification makes no attempts to address the question of authentication by a user from different devices.

Consider the following common use cases:

1. A user wishes to access their account from multiple devices that they trust; e.g., a desktop computer, a laptop computer, and a mobile device.
2. A user wishes to access their account from an untrusted device; e.g., a friend's laptop.

The specification doesn't include recommendations to implementers on how to address these common scenarios. Once a private key has been created, how does a user authorize other devices to gain access to the account?

Passwords are portable. As long as one recalls the password, an account can be accessed from any device. If Web Authentication has the goal to replace passwords, then it must address the issue of portability.

[nadalin]

I'm not sure this belongs in the spec as the implementation would not be effected, this is more on the users end on how to manage multiple authenticators

[cjthompson]

I agree as far as the protocol spec is concerned.

The draft spec does already include a section titled "Sample scenarios" that describes possible implementations for various scenarios. I'm suggesting that a new sample scenario to be added that suggests one possible way for an implementer to address the issue of portability.

My concern is that the protocol won't gain user acceptance if credentials are locked to a physical device.

[vijaybh]

@cjthompson , the primary sample scenario described in the spec does in fact show how to access an account from multiple devices. The user authenticates on their laptop (the client) with their phone (the authenticator) and can do the same thing on a different laptop as well. So just like they are able to access their account from any machine on which they can type their password, they can access the account from any machine that can talk to their phone. There doesn't seem to be anything special for the implementer or RP to do.

If you can explain a bit more how the text was confusing (i.e. why the sample scenarios did not seem to align with your expectations) then we can look at clarifying this text. Thanks!

[nadalin]

I believe in some cases like a TPM that this will be the case where the credetials are locked to s specific device and will not be portable

[cjthompson]

@vijaybh - I read through the sample scenarios a few times. While it doesn't explicitly cover the scenario that you describe, it seems clear that if the authenticator is a portable device of some kind, that would allow for logging in from multiple devices.

The Microsoft Account app works this way. I use a username/password to log into my account. A prompt is shown on my phone to accept the login. Once accepted, I am logged in as expected.

I believe my confusion stems from the scenario in which the user's browser is the authenticator. For example, my browser generates the public/private key pair and stores it in a local store (TPM or encrypted or whatever). If the browser generates and stores the key pairs, they lose their portability.

Would it be envisioned that some form of cloud storage of private keys could be used to sync private keys to multiple devices, similar to current password managers? Or, could a third-party website act as an authenticator in a similar way to how OAuth uses a third-party to authenticate a user? If that was true, then one would only need to remember authentication credentials for the third-party system, which would store all the user's private keys.

[nadalin]

The keys are held within the TPM and not exportable and thus are not stored in the cloud, this makes the credentials locked to a specific device

[cjthompson]

Could a third-party website act as an authenticator similar to OAuth?

[nadalin]

I guess I'm not following you as OAuth does not do authentication, only issues access tokens

[equalsJeffH]

Actually, I think @cjthompson has a point here -- note that in discussions wrt webauthn deployment approaches we (webauthn wg) have had, at least one RP is intending to not allow users to register creds that are held on a "non-portable" device, such as a laptop or desktop.

Also, an RP could allow users to register multiple credentials from multiple devices with their account.

Thus, this is further grist for an "implementation considerations" section and I've labled this issue with doc:impl-cons and left it open.

[selfissued]

I think that we could easily just close this, as credential portability is a non-goal. Or we could say in the Implementation Considerations spec saying that "credential portability is a non-goal" and then close it.

[equalsJeffH]

I think there's further nuances here and we should keep it open as-is as grist for an impl-cons section.

[emlun]

This is related to #842 and #422.

[paramsinghvc]

What's the solution to this? It's a very common scenario. People access web apps from their MacBook and phones separately. The credentials can't be ported. And, the webauthn mechanism works by storing the credentials in user machine which means multiple devices have multiple credentials. How does webauthn address this issue of authenticating on multiple devices then?
Developers won't be able to use it since this is the case.

[MasterKale]

@paramsinghvc It's going to be the responsibility of the service incorporating Webauthn as an authentication mechanism to coordinate associating multiple authenticators to a single internal user account.

Some types of FIDO2 devices, like Yubikeys, are most flexible in that they can be plugged into multiple devices and used to authenticate. Users could get away with registering a single such device and use it across their laptop, PC, phone, etc... In the case of, say, a MacBook Pro's Touch ID, the sensor is physically tied to the machine and so the user is going to be incapable of using it to log in from their PC. In this second scenario, it'd be up to the back end service to devise a way to empower a registered user to initiate a second attestation process from a logged-in device that would enable initiating attestation on a second device.

The solution to this is for dedicated individuals to start building "turnkey" solutions/packages/dependencies/etc... that make it easy for various frameworks to incorporate this into their authentication flows. I don't foresee this happening overnight, though. After building my own password-less Webauthn-powered OIDC Provider (@cjthompson this might interest you 😛) it became clear to me that there's a non-trivial amount of work required to generalize such functionality for reusability...

EDIT: Here's a simple corresponding RP I created to help demonstrate combining Webauthn with SSO: https://matts-peanut-butter-emporium.netlify.com

[paramsinghvc]

Thanks @MasterKale for throwing light on the same. I see that, you're sending a magic link on user's email which allows it to register a new device when he opens it on a given new device. Hmm, one has to get an email service provider for this; not that straight-forward but yeah makes sense.

[billchenchina]

Thanks @MasterKale for throwing light on the same. I see that, you're sending a magic link on user's email which allows it to register a new device when he opens it on a given new device. Hmm, one has to get an email service provider for this; not that straight-forward but yeah makes sense.

Well, you don't need an email service provider. Just provide user an OTP for them to login on a new device is just ok.

[bdewater]

@paramsinghvc you can use a roaming (USB/NFC/BT) authenticator to bootstrap registration of a new platform authenticator today but in the future a platform authenticator (phone) could connect over bluetooth to other devices (laptop) as well. See https://venturebeat.com/2019/04/10/you-can-now-use-your-android-phone-as-a-2fa-security-key-for-google-accounts/ and https://github.com/w3c/webauthn/pull/909

[Oloompa]

If your user want to sign in from a new device (because he lost/broke previous one or because he doesn't have it with him); is the solution to ask him for a password first and then register the new device ?

Webauthn seems not mature enough.

[emlun]

@Oloompa This problem is not new to WebAuthn: if a user wants to sign in but has forgotten their password, do you ask them for just their username and let them in anyway? If you lose your house key, do you use an override handle to unlock the door without it?

There is no single answer to your question; it will depend on the security requirements of the service, and perhaps the user.

Some services might just send an account recovery e-mail and call it good enough. Some might lock you out until you recover your authenticator or retrieve a backup authenticator you registered before losing the other one. Some might lock you out but provide some intentionally cumbersome account recovery options (see Google's Advanced Protection, for example). Some users might prefer the risk of getting locked out over the risk of someone abusing account recovery procedures to take over their account.

[mamartins]

One more common case that this solution doesn't address:

• I wipe my phone/get a new one, how can I login again on my account? An email isn't enough as it could be compromised. Unfortunately we still need to rely on other 2FA methods like TOTP, SMS, etc.

[emlun]

@mamartins This question has in fact been answered multiple times in this thread already: you use a roaming authenticator.

If these same questions keep coming back I will lock the thread.

[mamartins]

But making a USB Security Key mandatory isn't user friendly at all, and it can be lost too...

[arshadnoor]

There are a few things about FIDO2/WebAuthn that create confusion - unfortunately, the mess the authentication industry created over the last 20 years with the stupid "2FA" and "MFA" schemes they invented (instead of trying to make TLS ClientAuth simpler and easier) was primarily responsible for the mess. Leaving that rant aside for the moment, here are facts that might be helpful in understanding what makes FIDO2 easier to work with:

1) This is the first protocol that allows users to have multiple, unique cryptographic key-pairs associated with an account. For over half-a-century, people have been accustomed to associating an account with a single authentication credential, whether it is a single password or a single digital certificate + private-key, etc. FIDO shatters that paradigm and allows you to register dozens of public-keys with a website if you so choose to. When I demonstrate FIDO2, I show people that I have at least 8 public-keys registered from different devices to the demo account: a USB key, an NFC key, TouchID, Android resident-key, Windows Hello on the TPM, etc. I carry 3 different brands of Security Keys (on my keyring that has my home and car keys) to demonstrate that I've never lost that keyring or the Security Keys, and can authenticate to the same account with all these devices. Its not about affordability, or because we happen to be a FOSS FIDO2 Server manufacturer (and must consequently test with dozens of FIDO2 Authenticators); its about changing people's misconceptions that things have to be a certain way to be successfully adopted.: that there has to be one, universal FIDO2 Authenticator for the world to adopt it. Once you step back from that notion, and life becomes easier;

2) Depending on the secure element on a device, a key-pair does NOT have be locked down to a specific device - they can be ported if the secure element design supports a secure way of transporting keys from one device to another. In our experience, keys registered on a TPM can be ported to another TPM securely - through a process called "key-migration"; this has existed on TPMs since 1.2 (more than 12 years ago). I know this, because our appliances that provide key-management security have been using this capability to migrate encrypted keys from one appliance to another to establish key-management clusters for HA/DR. You can migrate signing-keys and encryption-keys (storage-keys in TPM terminology) very securely and conveniently with this TCG-defined process. However, you must have the tools to do this - the TCG spec tells you how to do this securely. What I cannot speak for are the secure elements on mobile devices and other platforms where resident keys are stored. The secure element manufacturers could attempt to provide a secure process to do this, but I wouldn't hold my breath - IMO, its cheaper to buy a $10 Security Key and use it as your own "migration tool" to create FIDO2 credentials on multiple devices to the same account.

I would encourage technologists to not get too hung up on trying to shield backup and recovery procedures from end-users - the more you dumb them down, the more headaches you create for the industry because somewhere along the way, someone is going to make a mistake and FIDO2/WebAuthn could get compromised because of implementation flaws. Better to let every Authenticator manufacturer create the most secure compartment they can key management, and users just learn to spend $10 on an external Security Key as a backup/recovery device.

Perhaps, we need to start calling "Security Keys" Backup Keys, Recovery Keys or Convenience Keys to get consumers educated that this is not to be shunned, but rather, to be embraced.

[Oloompa]

I still don't understand how both user and dev can handle generic use case of authentication without increasing complexity using this new protocol. This protocol seems to only help key manufacturers to make more money.

Do you really think i can ask my customer to buy a key in order to use my app ?
Do you think a user can use it's smartphone to sign in without any other way to sign in if he lost the smartphone ? (cause majority will not buy a key)
Do you think a user who buy two key will register each key on each app ?

I don't think this protocol will be use in its current state. It really looks terrible...

[mamartins]

@arshadnoor I do get your point, and I agree with it to a certain extent. Eventually everyone may embrace security keys and it will be an absurd consider that someone might not have one, but while that will probably be true in 10 years we can't ignore how today things work.
How security freak does a company have to be to risk going bankrupt because it's mandatory for its clients to buy a 10$ security key, so @Oloompa is also right. We have companies like Visa or Mastercard that prefer to keep their unsecure networks as it would be more costly (commercially) to do it instead of assuming fraud losses!

$10 might not look too much in USA or Europe but consider Asia or Latin America and things change dramatically. Companies cannot afford to obligate their users to spend money and at same time try to thrive commercially. Most of companies are trying to convince users to pay for their services to become profitable, now add the requirement that users will have to pay an extra $10 to be secure and they can mostly certain close their businesses.

[arshadnoor]

I don't disagree with the current economics @mamartins / @Oloompa. $10 is too expensive for APAC. For now. But, all new technologies go through this curve. What some industries should recognize is that it will be less expensive for them to give away Security Keys to customers than to waste time/money with all the other crap they buy/implement to do "risk scoring" on the back-end to minimize breaches and fraud.

Privacy laws are going to force companies to make a trade-off: do they just force consumers towards FIDO2 - a privacy protecting protocol (so long as you don't use a third-party IDP) - or waste more time/money trying to protect PII that they glean from the users platform? I think the economics are already in favor of forcing users towards FIDO2. The EU doled out 500M Euro of fines in 18 months of GDPR; California's Consumer Privacy Act ('the American GDPR) will allow consumers to sue companies for $750 per record per occurrence of a breach of PII; and California considers anything that can uniquely identify an individual to be PII, including IP addresses, "browser fingerprints", GPS locations, etc. Many US states are getting ready to pass their own privacy laws modeled along the lines of the CCPA (thanks to an incompetent Congress in Washington D.C.).

What makes sense in the long-run is for banks, brokerages, lawyers, accountants, etc. to start giving out a Security Key with their brand label to new customers who open accounts with them; for automobile companies to embed a FIDO2 Authenticator in their key-fobs; for car-rental companies and hotels to give away their branded FIDO2 keys to their Gold customers (I abandoned Marriott hotels after 25 years of using them and having achieved Platinum status because of their breach - I cannot tell you how many times I asked them to implement FIDO authentication on their site over the last 5 years); for luxury brand jewelry companies to embed secure elements within their watches, rings, necklaces, ear-rings, and for computer/laptop companies to include a FIDO2 Authenticator with each new computer purchased (in addition to the embedded secure element on their desktop/laptop).

Does this add costs to the product the consumer is buying? Yes, it does. But, considering the cost of what they're spending for the _other_ product they're buying, the $5 Security Key embedded in their primary product will be negligible and irrelevant. Not only will consumers win with a backup/recovery key on their key-chain, but so will Relying Party sites because they can eliminate some of the useless security products they buy to mitigate their risks on the back-end. And, they will be able to claim Strong Customer Authentication for GDPR, PSD2, CCPA, PDPA and all the other privacy laws that will blanket the world eventually.

We all need to see the future for what it will make possible for us if our systems and applications were more secure - not get bogged down with the current debris of passwords and 2FA/MFA junk that prevents us from achieving a more secure future.

[Oloompa]

@arshadnoor is right the majority of final customer will not move first to a dedicated key. The first step (for a final user) would be to use the device they own: their smartphone / watch.

And they will not buy a key for a long so if you want this protocol to be really used by business, the dev and users need a simple and secure way to recover from a single device lost.

If the only solution (for a device lost/broken/stolen) is to use the email/sms then this protocol offer nothing more except more works for dev teams and cost for users. Then it has no chance to be use in the real world.

[Ali-Amir]

I am a bit confused about a multi-device multi-website scenario and was wondering if someone could help me out with that:

A user uses their phone as their key and they are registered on a lot of websites with this phone (abc.xyz, example.com, etc) via some FIDO2 compliant authenticator app. At some point they will upgrade their phone (get a newer Pixel/iPhone/etc) and at that time what is the spec's recommendation for enabling the new phone on all of the existing accounts (abc.xyz, example.com, etc)?

There are approaches that an authenticator app could take to address that such as "securely" migrating existing credentials to the new device or forcing the user to manually add the device to the websites. But does FIDO2 provide a recommendation for which approach an authenticator app should take? My understanding from the thread is that this might be something outside of the specification and is the authenticator's reliability. But this seems like very common use case and it would be great to have a recommendation (unless it's already there and I missed it).

[nicksteele]

what is the spec's recommendation for enabling the new phone on all of the existing accounts (abc.xyz, example.com, etc)?

The WebAuthn specification doesn't have any recommendation for this flow, it would be up to the authenticator vendor (Apple, Google, Samsung, etc) to provide a secure method for the transference of key material. This doesn't mean the specification _couldn't_ help define this however, for example there could be a WebAuthn extension to help facilitate this, but realistically this would be something handled by the vendor.

My understanding from the thread is that this might be something outside of the specification and is the authenticator's reliability.

That's my understanding as well

Does FIDO2 provide a recommendation for which approach an authenticator app should take?

No, or at least not at this time. Personally I think this should be something defined by the authenticator vendors. As far as I know the only hardware vendor to write anything about this topic is Yubico with their work on the account recovery extension .

[emlun]

@Ali-Amir @nicksteele Yeah, this is still a mostly unsolved problem at this time, the spec offers no official guidance yet. There's more discussion on this and some proposed solutions in issue #931.

[Ali-Amir]

@nicksteele @emlun I see, thank you for confirming this. I will keep track of the linked issue.

[arshadnoor]

There are a few safety guards on such a use-case, Dominic. If you have a
Security Key that does not integrate biometrics or a PIN, and only
checks for "User Presence" (UP), then:

1) The attacker would have to know which websites have registered this
key - admittedly, this is a small hurdle because they will try it at the
most common larges sites first to see if it works - but most sites that
are concerned about security will still ask for a password if the
Security Key only supports UP (which is common with the older U2F
Security Keys);

2) The attacker has to know the username on the website to be able to
generate the correct response from the FIDO Server - there is not only a
challenge, but also a list of acceptable "key handles", public-keys and
other metadata that will authenticate the response. While you might try
to guess at what the username might be, it might work, it might not -
but its still another hurdle.

If you really want to be secure on a site you consider too risky to be
compromised on, get yourself a "user verifying" (UV) Security Key - with
a biometric reader or a PIN; this will add another factor of protection
to your account if you lose the Security Key.

Right now, I don't know of any site that accepts a Security Key without
asking for your username AND password before presenting the FIDO
challenge. The only financial site I know at that accepts a Security Key
is Vanguard; it still requires authenticating with a username/password
before you see the FIDO challenge. Their policy is that they only accept
Yubikeys; I'm not happy with that and have complained. They claim
they're updating their site to accept other Security Keys - but it
either reflects little understanding of FIDO or they thought they were
being very risk-averse by accepting just one brand of Security Keys. I
wonder if they know about this paper yet - Yubikey and Feitian are also
implicated in the story besides Google:

https://arstechnica.com/information-technology/2021/01/hackers-can-clone-google-titan-2fa-keys-using-a-side-channel-in-nxp-chips/

Arshad Noor
StrongKey

On 1/10/21 7:29 AM, Dominic Tobias wrote:

I don't disagree with the current economics @mamartins
<https://github.com/mamartins> / @Oloompa
<https://github.com/Oloompa>. $10 is too expensive for APAC. For
now. But, all new technologies go through this curve. What some
industries should recognize is that it will be less expensive for
them to give away Security Keys to customers than to waste
time/money with all the other crap they buy/implement to do "risk
scoring" on the back-end to minimize breaches and fraud.

This is an interesting point, maybe I'm naive here but I have a Yubikey
and it has nothing that authenticates me. All someone needs to do is
steal/find it and have access to my accounts. How is that more secure
than a password!?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/w3c/webauthn/issues/151#issuecomment-757494694, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABWSVTSJ3BY6GBTDA74RJ6LSZHBUBANCNFSM4CKV35SA.