Enrolment strategies for FIDO2/WebAuthn when using built in authenticators
80 views
Skip to first unread message
Paul McNamara
Oct 5, 2021, 5:52:32 AM10/5/21
to FIDO Dev (fido-dev)
I posted this on StackOverflow originally but figured this place would be a bit more active when it comes to FIDO2 questions. I think there's only 4 or 5 regular answer posters on there (but thankyou Yuriy for your reply).
This is more of a philosophical question/request for comment rather than a technical one but I think it's still relevant even if it boils down more to UX design than anything else.
It's 2021, hardly anyone has a Yubikey or similar but nearly everyone has a phone, tablet or desktop/laptop with a TPM and an OS or browser that supports FIDO2 & WebAuthn. Therefore I'd like to explore ways to make the built-in authenticator enrollment process as slick as possible and not require them to have conventional password auth in place (even temporarily) to allow it to be done.
Is anyone aware of an approach out in the wild similar to the OpenID Connect device flow whereby someone could go to a public enrollment endpoint, do the credential creation ceremony for their device and then use a resulting unique code to link it to an account on another already enrolled device?
I'd see it working something like this:
- User visits https://idp.mycompany.com/enroll via link or some instructions
- They hit the "enroll this device" button and trigger the create credential interaction (would likely need to prompt for the user ID here as we'd need it to set up the resident key)
- We store the resulting credential in the backend and exchange for a unique code (e.g. ABC123)
- User visits https://idp.mycompany.com/enroll/ABC123 on an already enrolled device (or possibly accesses an UI where the code can just be typed in)
- User is prompted to authenticate using the resident key on their already enrolled device
- Once the user is signed in the stored credential is added to the user account in question and they receive a visual confirmation
- User is able to sign in using the credential on their newly enrolled device
This feels to me to be pretty secure as even if a code could be guessed the worst you could do would be to add someone else's credential to your account and since this is happening in an authenticated context we can implement rate limiting easily. The user would be free to manage their credentials after the fact however they see fit via a management UI.
Step 2 is probably the bit that's least clear for me but my thinking is that it doesn't really matter if the user provides garbage user details for the resident key as we'll be linking based on the credential ID in the backend anyway. If they put nonsense in then they're just impacting their own UX and nothing else and will be free to correct the mistake if they wish.
Thoughts?
Tim Cappalli
Oct 5, 2021, 9:01:20 AM10/5/21
to mcnama...@gmail.com, fido...@fidoalliance.org
So the user never provides any form of initial identity and can arbitrarily enter a username that will be bound to the credential?
This type of flow is generally handled using identity proofing (by presenting a VC or other artifact) and a temporary PIN.
From: fido...@fidoalliance.org <fido...@fidoalliance.org> on behalf of Paul McNamara <mcnama...@gmail.com>
Sent: Tuesday, October 5, 2021 5:52:32 AM
To: FIDO Dev (fido-dev) <fido...@fidoalliance.org>
Subject: [FIDO-DEV] Enrolment strategies for FIDO2/WebAuthn when using built in authenticators
Sent: Tuesday, October 5, 2021 5:52:32 AM
To: FIDO Dev (fido-dev) <fido...@fidoalliance.org>
Subject: [FIDO-DEV] Enrolment strategies for FIDO2/WebAuthn when using built in authenticators
--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/7e06a60b-11db-4b2e-9ef9-7586b8d72d50n%40fidoalliance.org.
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/7e06a60b-11db-4b2e-9ef9-7586b8d72d50n%40fidoalliance.org.
Shane Weeden
Oct 5, 2021, 5:00:23 PM10/5/21
to FIDO Dev (fido-dev), Tim Cappalli, Paul McNamara
To play devils advocate for a moment. I think part of the scenario is not entirely spelled out here.
Consider the question, "How did the user authenticate on their original device, and why is that not an appropriate bootstrap sign-in method for the new device prior to then registering the platform authenticator?"
The OAuth device registration flow is/was specifically targeted at devices that don't have easy to use traditional human input devices (keyboard, etc) such as a smart TV or appliance.
The OAuth device registration flow is/was specifically targeted at devices that don't have easy to use traditional human input devices (keyboard, etc) such as a smart TV or appliance.
The flow you are suggesting is entirely possible, but is it needed, or necessarily more practical than a traditional new device sign-in method?
Happy to explore this idea though - it's an interesting topic.
Cheers,
Shane.
Arshad Noor
Oct 6, 2021, 10:16:13 PM10/6/21
to Paul McNamara, FIDO Dev (fido-dev)
Hi Paul,
Try a couple of different registration flows we've setup:
1) https://demo.strongkey.com
2) https://demo.strongkey.com/fidopolicy (please be patient - its on a
low-horsepower machine for now)
The second URL is more interesting. It demonstrates a capability in our
open-source FIDO Certified server, which allows you to configure unique
policies and enforce that within the application without having to code
anything into the application - if the registration/authentication
conforms to the policy, you're in.
Because this is a demonstration, there is no ID&V process involved. The
first URL sign-up requires an e-mail to send you a link to register, and
a mobile number to get an OTP before you're in.
Hope it provides some insights.
Arshad Noor
StrongKey
On 10/5/21 2:52 AM, Paul McNamara wrote:
> I posted this on StackOverflow originally but figured this place would
> be a bit more active when it comes to FIDO2 questions. I think there's
> only 4 or 5 regular answer posters on there (but thankyou Yuriy for your
> reply).
>
> This is more of a philosophical question/request for comment rather than
> a technical one but I think it's still relevant even if it boils down
> more to UX design than anything else.
>
> It's 2021, hardly anyone has a Yubikey or similar but nearly everyone
> has a phone, tablet or desktop/laptop with a TPM and an OS or browser
> that supports FIDO2 & WebAuthn. Therefore I'd like to explore ways to
> make the built-in authenticator enrollment process as slick as possible
> and not require them to have conventional password auth in place (even
> temporarily) to allow it to be done.
>
> Is anyone aware of an approach out in the wild similar to the OpenID
> Connect device flow whereby someone could go to a public enrollment
> endpoint, do the credential creation ceremony for their device and then
> use a resulting unique code to link it to an account on another already
> enrolled device?
>
> I'd see it working something like this:
>
> 1. User visits https://idp.mycompany.com/enroll
> unique code (e.g. ABC123)
> 4. User visits https://idp.mycompany.com/enroll/ABC123
> already enrolled device
> 6. Once the user is signed in the stored credential is added to the
Try a couple of different registration flows we've setup:
1) https://demo.strongkey.com
2) https://demo.strongkey.com/fidopolicy (please be patient - its on a
low-horsepower machine for now)
The second URL is more interesting. It demonstrates a capability in our
open-source FIDO Certified server, which allows you to configure unique
policies and enforce that within the application without having to code
anything into the application - if the registration/authentication
conforms to the policy, you're in.
Because this is a demonstration, there is no ID&V process involved. The
first URL sign-up requires an e-mail to send you a link to register, and
a mobile number to get an OTP before you're in.
Hope it provides some insights.
Arshad Noor
StrongKey
On 10/5/21 2:52 AM, Paul McNamara wrote:
> I posted this on StackOverflow originally but figured this place would
> be a bit more active when it comes to FIDO2 questions. I think there's
> only 4 or 5 regular answer posters on there (but thankyou Yuriy for your
> reply).
>
> This is more of a philosophical question/request for comment rather than
> a technical one but I think it's still relevant even if it boils down
> more to UX design than anything else.
>
> It's 2021, hardly anyone has a Yubikey or similar but nearly everyone
> has a phone, tablet or desktop/laptop with a TPM and an OS or browser
> that supports FIDO2 & WebAuthn. Therefore I'd like to explore ways to
> make the built-in authenticator enrollment process as slick as possible
> and not require them to have conventional password auth in place (even
> temporarily) to allow it to be done.
>
> Is anyone aware of an approach out in the wild similar to the OpenID
> Connect device flow whereby someone could go to a public enrollment
> endpoint, do the credential creation ceremony for their device and then
> use a resulting unique code to link it to an account on another already
> enrolled device?
>
> I'd see it working something like this:
>
> <https://idp.mycompany.com/enroll> via link or some instructions
> 2. They hit the "enroll this device" button and trigger the create
> credential interaction (would likely need to prompt for the user ID
> here as we'd need it to set up the resident key)
> 3. We store the resulting credential in the backend and exchange for a
> here as we'd need it to set up the resident key)
> unique code (e.g. ABC123)
> 4. User visits https://idp.mycompany.com/enroll/ABC123
> <https://idp.mycompany.com/enroll/ABC123> on an already enrolled
> device (or possibly accesses an UI where the code can just be typed in)
> 5. User is prompted to authenticate using the resident key on their
> device (or possibly accesses an UI where the code can just be typed in)
> already enrolled device
> 6. Once the user is signed in the stored credential is added to the
> user account in question and they receive a visual confirmation
> 7. User is able to sign in using the credential on their newly enrolled
> device
>
> This feels to me to be pretty secure as even if a code could be guessed
> the worst you could do would be to add someone else's credential to your
> account and since this is happening in an authenticated context we can
> implement rate limiting easily. The user would be free to manage their
> credentials after the fact however they see fit via a management UI.
>
> Step 2 is probably the bit that's least clear for me but my thinking is
> that it doesn't really matter if the user provides garbage user details
> for the resident key as we'll be linking based on the credential ID in
> the backend anyway. If they put nonsense in then they're just impacting
> their own UX and nothing else and will be free to correct the mistake if
> they wish.
>
> Thoughts?
>
>
>
>
> This feels to me to be pretty secure as even if a code could be guessed
> the worst you could do would be to add someone else's credential to your
> account and since this is happening in an authenticated context we can
> implement rate limiting easily. The user would be free to manage their
> credentials after the fact however they see fit via a management UI.
>
> Step 2 is probably the bit that's least clear for me but my thinking is
> that it doesn't really matter if the user provides garbage user details
> for the resident key as we'll be linking based on the credential ID in
> the backend anyway. If they put nonsense in then they're just impacting
> their own UX and nothing else and will be free to correct the mistake if
> they wish.
>
> Thoughts?
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "FIDO Dev (fido-dev)" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to fido-dev+u...@fidoalliance.org
> <mailto:fido-dev+u...@fidoalliance.org>.
> You received this message because you are subscribed to the Google
> Groups "FIDO Dev (fido-dev)" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to fido-dev+u...@fidoalliance.org
> To view this discussion on the web visit
> https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/7e06a60b-11db-4b2e-9ef9-7586b8d72d50n%40fidoalliance.org
> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/7e06a60b-11db-4b2e-9ef9-7586b8d72d50n%40fidoalliance.org?utm_medium=email&utm_source=footer>.
> https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/7e06a60b-11db-4b2e-9ef9-7586b8d72d50n%40fidoalliance.org
Paul McNamara
Oct 7, 2021, 8:28:13 AM10/7/21
to FIDO Dev (fido-dev), Arshad Noor, Paul McNamara
The more I ponder it the more I worry that what I've proposed would possibly open up a vector for phishing attacks. My initial thought was that it's the account owner that would be the bad actor but ofcourse the credential creator could also be up to no good and convince another user to attach the bad actor's credential to their account. This goes for the OIDC/OAuth2 device flow in general too (Google it). In both cases providing a link to an end user could allow a credential that does not belong to a user to be attached to their account or even grant access to an account that would then allow their own credentials to be attached.
In short I think it's actually less secure than a simple temporary password that the user deactivates once they don't need it anymore.
Arshad Noor
Oct 7, 2021, 11:17:37 AM10/7/21
to Paul McNamara, FIDO Dev (fido-dev)
There are ways to mitigate these risks if one constrains users to some
extent. Here's one scheme that would work as long as you've built in the
appropriate cryptographic controls for authenticity, confidentiality and
integrity:
https://github.com/w3c/webauthn/issues/1656#issuecomment-889050199
You may need to review the thread from the first post to get some
background on the context.
Arshad
On 10/7/21 5:28 AM, Paul McNamara wrote:
> The more I ponder it the more I worry that what I've proposed would
> possibly open up a vector for phishing attacks. My initial thought was
> that it's the account owner that would be the bad actor but ofcourse the
> credential creator could also be up to no good and convince another user
> to attach the bad actor's credential to their account. This goes for the
> OIDC/OAuth2 device flow in general too (Google it). In both cases
> providing a link to an end user could allow a credential that does not
> belong to a user to be attached to their account or even grant access to
> an account that would then allow their own credentials to be attached.
>
> In short I think it's actually less secure than a simple temporary
> password that the user deactivates once they don't need it anymore.
>
>
>
> On Thursday, 7 October 2021 at 03:16:13 UTC+1 Arshad Noor wrote:
>
> Hi Paul,
>
> Try a couple of different registration flows we've setup:
>
> 1) https://demo.strongkey.com <https://demo.strongkey.com>
> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/7e06a60b-11db-4b2e-9ef9-7586b8d72d50n%40fidoalliance.org?utm_medium=email&utm_source=footer
> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/7e06a60b-11db-4b2e-9ef9-7586b8d72d50n%40fidoalliance.org?utm_medium=email&utm_source=footer>>.
> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/c1797353-6bca-4811-b4cc-bd6547614164n%40fidoalliance.org?utm_medium=email&utm_source=footer>.
extent. Here's one scheme that would work as long as you've built in the
appropriate cryptographic controls for authenticity, confidentiality and
integrity:
https://github.com/w3c/webauthn/issues/1656#issuecomment-889050199
You may need to review the thread from the first post to get some
background on the context.
Arshad
On 10/7/21 5:28 AM, Paul McNamara wrote:
> The more I ponder it the more I worry that what I've proposed would
> possibly open up a vector for phishing attacks. My initial thought was
> that it's the account owner that would be the bad actor but ofcourse the
> credential creator could also be up to no good and convince another user
> to attach the bad actor's credential to their account. This goes for the
> OIDC/OAuth2 device flow in general too (Google it). In both cases
> providing a link to an end user could allow a credential that does not
> belong to a user to be attached to their account or even grant access to
> an account that would then allow their own credentials to be attached.
>
> In short I think it's actually less secure than a simple temporary
> password that the user deactivates once they don't need it anymore.
>
>
>
> On Thursday, 7 October 2021 at 03:16:13 UTC+1 Arshad Noor wrote:
>
> Hi Paul,
>
> Try a couple of different registration flows we've setup:
>
> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/7e06a60b-11db-4b2e-9ef9-7586b8d72d50n%40fidoalliance.org?utm_medium=email&utm_source=footer>>.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "FIDO Dev (fido-dev)" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to fido-dev+u...@fidoalliance.org
> <mailto:fido-dev+u...@fidoalliance.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/c1797353-6bca-4811-b4cc-bd6547614164n%40fidoalliance.org
>
> --
> You received this message because you are subscribed to the Google
> Groups "FIDO Dev (fido-dev)" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to fido-dev+u...@fidoalliance.org
> <mailto:fido-dev+u...@fidoalliance.org>.
> To view this discussion on the web visit
> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/c1797353-6bca-4811-b4cc-bd6547614164n%40fidoalliance.org?utm_medium=email&utm_source=footer>.
Paul McNamara
Oct 7, 2021, 1:34:06 PM10/7/21
to FIDO Dev (fido-dev), Arshad Noor, Paul McNamara
Interesting discussion Arshad. I noted your minor rant ;) - I too would love to see this take off but I think solving this registration problem is key to that success.
I think I'll need to sleep on it for a few more nights.
Do you have any throughts on the account recovery aspect too?
Arshad Noor
Oct 7, 2021, 2:47:22 PM10/7/21
to Paul McNamara, FIDO Dev (fido-dev)
What I've been promoting since 2015, Paul: buy a Security Key and lock
it up in a drawer. There are enough choices to satisfy most people.
I've suggested that manufacturers of computers and mobiles include
Security Keys for every device they ship (for branding, loyalty and just
plain elevating humanity to a new level of consciousness). It might add
a few dollars to the product, but it would save us all from this
seemingly endless madness.
(Apologies: I just wasted an hour trying to reset my password on a site
operated by the Dept. of Homeland Security and had to call their
Customer Support twice. How will this craziness stop if we don't stop
complicating FIDO/WebAuthn and just get everybody on this train first?)
Arshad
> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/c1797353-6bca-4811-b4cc-bd6547614164n%40fidoalliance.org?utm_medium=email&utm_source=footer
> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/c1797353-6bca-4811-b4cc-bd6547614164n%40fidoalliance.org?utm_medium=email&utm_source=footer>>.
> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/1d793a45-e86b-4a55-b4f8-d23970aeda95n%40fidoalliance.org?utm_medium=email&utm_source=footer>.
it up in a drawer. There are enough choices to satisfy most people.
I've suggested that manufacturers of computers and mobiles include
Security Keys for every device they ship (for branding, loyalty and just
plain elevating humanity to a new level of consciousness). It might add
a few dollars to the product, but it would save us all from this
seemingly endless madness.
(Apologies: I just wasted an hour trying to reset my password on a site
operated by the Dept. of Homeland Security and had to call their
Customer Support twice. How will this craziness stop if we don't stop
complicating FIDO/WebAuthn and just get everybody on this train first?)
Arshad
> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/c1797353-6bca-4811-b4cc-bd6547614164n%40fidoalliance.org?utm_medium=email&utm_source=footer>>.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "FIDO Dev (fido-dev)" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to fido-dev+u...@fidoalliance.org
> <mailto:fido-dev+u...@fidoalliance.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/1d793a45-e86b-4a55-b4f8-d23970aeda95n%40fidoalliance.org
>
> --
> You received this message because you are subscribed to the Google
> Groups "FIDO Dev (fido-dev)" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to fido-dev+u...@fidoalliance.org
> <mailto:fido-dev+u...@fidoalliance.org>.
> To view this discussion on the web visit
> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/1d793a45-e86b-4a55-b4f8-d23970aeda95n%40fidoalliance.org?utm_medium=email&utm_source=footer>.
Reply all
Reply to author
Forward
0 new messages