Clarify how a user can authenticate from multiple devices #151
Comments
|
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 |
|
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. |
|
@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! |
|
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 |
|
@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. |
|
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 |
|
Could a third-party website act as an authenticator similar to OAuth? |
|
I guess I'm not following you as OAuth does not do authentication, only issues access tokens |
|
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. |
|
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. |
|
I think there's further nuances here and we should keep it open as-is as grist for an impl-cons section. |
|
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? |
|
@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 |
|
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. |
|
@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 #909 |
|
Thanks.... and, yeah, it seems like I have to initiate WebAuthn with some user interaction, and let them figure out if it'll work. Giving authenticator an ID is a bad idea, though, on second thought. Assuming it survives clearing the browser data, then it's an ID advertisers would misuse. Edit: To be clear, I wasn't suggesting the need for portable keys. I was arguing that something is needed to support a better user experience whenever the current device isn't the one registered with the server for a given user. |
|
At the end of the day @knightcode this is something that webauthn has left to be resolved by RP's to work out the UX flow for when you have multiple devices/browsers, or multiple authenticators available. I think we'll see multiple different ways that people end up managing this, especially once you consider non-homogenous authenticator classes that webauthn by design can't mix/match. |
Would you like to elaborate on this? This is definitely not an intentional design goal, if I understand correctly what you mean. |
|
I'm fully aware that my current implementation might be flawed, but I guess what I was hoping to do is ask our server for a challenge and credential IDs as soon as the username/email field is blurred. If IDs come back, it'd be nice to trigger webauthn automatically and get back a failure saying "none of these IDs are here" which also doesn't trigger any native browser UI, so that I don't have to let the user know that we failed trying to do something they didn't even ask for... presumably, he/she/ze already knows that it was going to fail. This is opposed to other errors where maybe it's appropriate to inform the user that we tried but it's not working. Chrome, at least, was still engaging its UI to inform the user that none of the keys provided were available. Given this, I've pushed the webauthn flow to an auxiliary thing. The primary UI is still username/password + maybe OTP, and a button was added for the user to trigger webauthn if they feel like it. |
The desire is quite understandable but we can't allow websites to silently probe the browser for the user's identity for the obvious reasons.
For 1st-factor WebAuthn, that's correct. The answer in the future will be that browsers will support WebAuthn via autofill (#1637) so that the browser can present the user a list of applicable credentials when focusing the username field. |
I have a write up on the topic here: https://github.com/kanidm/webauthn-rs/blob/master/designs/authentication-use-cases.md the tl;dr is you can't mix verified and un-verified credentials, or resident/non-resident credentials. The UI must always perform pre-selection to help select what challenges can be sent to navigator.credentials.get. So even if devices can share credentials, there still is an expectation on RP's to implement a UX to do filtering of what can proceed. |
The website is providing a list of IDs it knows about, though. And it seems like the ID space is huge. If the query limits possible hits to the current web domain only, the danger is that a script might start silently iterating through all possible IDs to find the one or two working keys on this device? That's the danger? |
|
@knightcode Correct, but remember that techniques like browser fingerprinting can likely narrow the searchable space down to a manageable size. Then the website could use the silent probe to exactly identify the user without the user's consent. This does presuppose that the user has at some point authorized a credential creation for that site, but it's far easier to confuse a user into doing that once than into doing it every time you want to identify them. |
@MasterKale what IdP you use for magic links & webauthn in your demo, can you please share? Is it possible to use it for free ? |
Jeff. This is exactly what we have done in our implementation. |
|
Why was this issue closed? I couldn't find a clarification of how a user can auth from multiple devices. The solution isn't roaming auth (confusing name btw)—Webauthn's core isn't about using something like an external Yubikey. If I wanted auth via Yubikey I could use a couple of other ways than \Webauthn to authenticate. |
|
The methods of authentication are basically implementation specific. A user may have a cross-platform aithenticator where this does not exist as a barrier. Or they may choose to use a platform authenticator where there are two options; the implementation of the platform authenticator offers the ability to export the credential to another device via sync or other means.. or the user registers a platform authenticator with the relevant relying party (think this is the terminology.. basically the service trusting the credentials) for each device they want to authenticate with. I think the reason this is closed is because it's out of scope for the specification since it covers the method of authentication not the individual implementation mechanics of every facet of webauthn. |
It is, though. If you want to (1) log in from multiple devices, but (2) always enforce WebAuthn authentication for every login and (3) not copy private keys, then your only option is to use an authenticator with multiple connectivity options. Otherwise you'll have to relax at least one of the requirements (1), (2) and (3). Some (most?) websites do relax (2) and allow some other method of 2FA or account recovery. Some authenticator vendors relax (3) and copy private keys between devices via cloud sync or similar. But note that a "roaming authenticator" doesn't have to be a YubiKey or similar "security key" device, it can also be a smartphone for example. Mobile OS vendors are now starting to support acting as a roaming authenticator via Bluetooth. This means a platform credential on the phone can be used both as a "built-in" credential on the phone and as a roaming credential on other devices. |
|
My company is planning on implementing password-less auth using text message verification codes. I decided to investigate Webauthn as an alternative to sending text messages, primarily to reduce the cost of sending text messages. However, I don't think I can recommend Webauthn as a replacement for sending text messages for password-less auth. I think the concern of authenticating from multiple devices is real. While using a smart phone as a roaming authenticator, at least in the US, sounds promising. It is still susceptible to the phone being lost, stolen, broken, restored, or replaced. At which point the user would be locked out and a second form of authentication will be necessary to restore access. At least with text messages, the user would regain access as soon as they could start receiving text messages again. It is also unclear what the flow would be to get the user to use their phone as the authenticator when they are registering, for the first time, from their laptop for example. I don't think it is reasonable to expect people to use a secondary external device to authenticate on their phone. In other words, I don't think it is reasonable to expect people to plug a yubikey into their phone to authenticate. At least not at this time. |
|
@daniel-nagy you might want to take a look at how WebAuthn will evolve into passkeys until the end of the year. Especially on Apple and Android devices your use case should be pretty much covered. I suggest you base your regular login on passkeys, and only fall back to text messages on older devices or in case a user loses their passkey device and switches the platform, e.g. from iOS to Android. |
|
Thanks @FlxMgdnz, passkeys look promising. It seems text message verification codes will still be necessary but passkeys could reduce the number of text messages and improve the UX after the user is registered on supported platforms. |
Passkeys fall under the relax of point 3 that @emlun mentioned as they will be synced via iCloud, right? |
Yes – if you compromise someone's iCloud account, manage to sign in on a device under your control, and set up Face ID on that device. Apple more or less enforces 2FA for Keychain access to prevent such an attack on credentials from happening. But there are certainly cases where this threat model is not acceptable, e.g. under certain regulations (in their current form at least). |
|
Let's bring this implementation discussion over to the WebAuthn Community Adoption Group since it is talking about individual vendors. |
Yes, that is exactly correct. Compromise of the iCloud account, now compromises all passkeys associated to the account. |
Apple have now officially confirmed to me, that they are not willing to support attested single device credentials on iOS16 or Ventura going forward, meaning that there is no way to "avoid" passkeys. You either need to attest credentials and reject passkeys and all apple platform authenticators, or you will need to accept passkeys and their risks. |
|
Up until now, especially for the native application, the RP has a control to enable/disable (by default, disabled) backup the data (including credentials - such as private keys) to the platform provider's cloud. Some RPs might enable such features to improve the usability or reduce the customer drop off rate when they access the RPs again with new device. After introducing the passkey, the control is out of RPs and even the user might not have any choice. So if the platform vendors' choice is defaulting passkey, then at least, for the RPs concerning the security or having own security requirements, we should provide a way to leverage. If the DPK is just only for hinting of device continuity, something more is needed for the RP (maybe fallback/identity proofing, or passwords). |
What will happen to existing (attested) registrations of Apple authenticator? |
This is so asinine and typical of them. They should be on-device keys by default and it should allow you to convert them to passkeys with a button with a 2FA validation. |
They will continue to work, but new registrations will be subject to the above. |
That's not actually possible to turn an on-device key into a passkey. The distinction as Apple previously stated was attested -> on device, non-attested -> passkeys. Now they have backtracked, and they will only provided non-attested passkeys in all cases, so on-device keys are not possible. |
Does it mean we can remove Apple attestation from WebAuthn spec? |
|
I don't think so. Apple allow attestation in certain device managed cases, but not for general consumers / bring your own device. |
Even if we would, it would remain in the registry and there's no reason authenticators shouldn't use it. |
and others
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:
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.
The text was updated successfully, but these errors were encountered: