Add Passwordless MFA Column

[bsimic0001]

I promise I read the contributions page before submitting this. Specifically the passwordless section.

Several sites now support FIDO based Passwordless MFA options for users. This includes Gemini.com for example which allows users to configure a FIDO2 platform authenticator such as the Windows Hello or Mac Touch ID capability. This is considered multi-factor by all major sources because it is something you have (the private key on the hardware) and something you are (the biometric).

Additionally, FIDO2 security keys such as the Yubikey Bio or even regular Yubikeys are multi-factor because they can be only used with a PIN (something you know) along side the hardware backed private key (something you have).

These methods are much more secure and more importantly, they are phishing resistant because they are not susceptible to attacks by tools such as Modlishka which act as a Man In The Middle (MITM) proxy to intercept credentials.

it is also important to mention that some companies incorporate these capabilities into their native mobile applications where the user is seemingly using a Touch ID but it's multi factor because it's combined with a private key that's stored on a hardware backed keystore. It will be important to distinguish between Touch ID that is essentially a UX layer in front of a password versus a FIDO Alliance Certified implementation.

[Carlgo11]

This is considered multi-factor by all major sources

Do you have any independent sources to reference this claim? I think I speak for the entire team when I say that we don't regard FIDO2 to be more than one factor.

[normanfield]

The payments industry considers FIDO2 (with user verification enabled) as two factors. The European Union's Payment Services Directive (PSD2) defines a requirement for Strong Customer Authentication (SCA), which requires two factors. VISA and Mastercard are heavily invested in FIDO2 for this reason. The following white paper describes how FIDO2 meets those stringent requirements: https://fidoalliance.org/how_fido_meets_the_rts_requirements/

Relevant content from the white paper:
_Requirement:
The authentication shall be based on two or more elements which are categorised as knowledge, possession and inherence and shall result in the generation of an authentication code

How FIDO meets it:
To authenticate with FIDO, the Payment Service User (PSU) must possess a FIDO authenticator that is either integrated in a general purpose device (e.g. Smartphone, Laptop, …) or in a separate device (e.g. Security Key, smart card…). As seen in chapter 2 of this document, possession of such a FIDO authenticator satisfies the first of the two elements required to authenticate the PSU.

The second element required to authenticate the PSU consists in:

• For U2F, a password sent on-line and verified by the server
• For UAF and FIDO2, an inherence (biometric) factor or knowledge (PIN) factor verified locally by the FIDO authenticator

The signed response, created by the authenticator and returned to the ASPSP, constitutes the authentication code mandated by the RTS._

EMVco has published a white paper on how they are integrating FIDO into the credit card payments flow (https://www.emvco.com/wp-content/uploads/documents/EMVCo_3DS_FIDOData-WPv1.0_20200710.pdf). This paper doesn't discuss the authentication factors, but confirms that FIDO2 is being used in a context requiring 2FA.

[rlin1]

Some references for allowing a single authenticator to provide multiple factors (e.g. 2FA) here:
a) NIST SP 800-63 3B, see https://pages.nist.gov/800-63-3/sp800-63b.html

• see section 5.1.8.1 Multi-Factor Cryptographic Software Authenticator and
• section section 5.1.9.1 Multi-Factor Cryptographic Device Authenticators
• An explanation is given in https://www.slideshare.net/FIDOAlliance/nist-80063-guidance-fido-authentication

b) PSD2 RTS Article 9 "Independence of Elements". See https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32018R0389&from=EN. This article 9 specifies the requirements for a single Authenticator to provide 2 independent authentication factors.

[rlin1]

WebAuthn is specifically mentioned to provide MFA in https://zerotrust.cyber.gov/federal-zero-trust-strategy/#identity

[jgrantindc]

As the guy who used to run the digital identity team at NIST, I'm pretty comfortable saying that NIST and other governments (the UK, Australia, EU) all look at FIDO2 as MFA, be it delivered via a security key (like a Yubikey) or through an authenticator built into a smartphone or laptop.

NIST SP 800-63B (Digital Identity Guidelines - Authentication and Lifecycle Management) describes a "Multi-Factor Cryptographic Device" as one type of authenticator and specifically included a picture of a smartphone to make clear that use cases like those using FIDO authenticators that are integrated in a device are covered. Per section 5.1.9, a "multi-factor cryptographic device is something you have, and it SHALL be activated by either something you know or something you are." See https://pages.nist.gov/800-63-3/sp800-63b.html

Security Keys are considered "Single-Factor Cryptographic Devices: per section 5.1.7 - it is assumed that they would be used in conjunction with a second factor such as a password.

NIST made this clearer in its subsequent publication of "Implementation Resources" to support SP 800-63-3, noting "Multi-factor cryptographic devices can also be embedded in endpoints, as is the case of FIDO UAF authenticators." See https://www.nist.gov/system/files/documents/2020/07/02/SP-800-63-3-Implementation-Resources_07012020.pdf

Both the UK and Australian governments formally point back to NIST SP 800-63B in their own authentication standards and guidance.

While I am now out of government, the USG's embrace of FIDO as not only MFA but the preferred approach to MFA has only gotten stronger. The new White House Zero Trust Strategy makes clear that agencies have to use not just any MFA but specifically phishing-resistant MFA. And it calls out WebAuthN by name as the standard that agencies should look to use here. https://zerotrust.cyber.gov/federal-zero-trust-strategy/#identity

The White House strategy also highlights that other legacy MFA is now phishable as part of its justification for pushing agencies to use FIDO2/WebAuthn, noting "many approaches to multi-factor authentication will not protect against sophisticated phishing attacks, which can convincingly spoof official applications and involve dynamic interaction with users. Users can be fooled into providing a one-time code or responding to a security prompt that grants the attacker account access. These attacks can be fully automated and operate cheaply at significant scale."

The Federal government's CISO reiterated this point in an article just before Christmas, saying: "Identity is a key pillar of the U.S. government’s zero trust strategy, and a significant component of that is ensuring federal agencies use strong multi-factor authentication that defends against phishing, one of the most common enterprise threat vectors...To achieve this consistently, we expect that federal agencies will need to complement their use of PIV with devices that support FIDO2 and Web Authentication standards, while phasing out weaker approaches that provide less protection against real-world phishing campaigns.” https://www.nextgov.com/cybersecurity/2021/12/federal-ciso-clarifies-support-standard-could-make-passwords-history/360191/

And CISA published guidance just over a year ago to election entities calling out the FIDO2 standard as the preferred approach to MFA and cautioning implementers about the vulnerability of OTP apps to phishing attacks. https://www.cisa.gov/sites/default/files/publications/CISA_Insights_Actions_to_Counter_Email-Based_Attacks_on_Election-Related_S508C.pdf

I am happy to provide more resources if helpful, but this seems to be an issue that was settled quite some time ago.

[bsimic0001]

@Carlgo11 are the above references sufficient?

[Carlgo11]

Thanks for all the reading material 😅 . It's clear that you have some very knowledgeable gov/lobby friends @bsimic0001.
Just to be clear, we do list FIDO2/WebAuthn/FIDO U2F already but as a single factor. Some links seemed to be about the strengths of FIDO 2 which I don't dispute, just the logic of one operation to be more than one authentication factor.

I'll add your feature request to the to-do list but as we're practically a team of three doing this on our spare time I can't give an ETA of when we'll touch the ticket.

[rlin1]

Note: In FIDO (except U2F), there is the notion of User Verification versus User Presence. When someone presents the Authenticator and presses a button (i.e. User Presence) this is considered a single (possession) factor.
When the User presents the authenticator and is verified by the authenticator (i.e. User Verification, e.g. though biometrics or a clientPIN), then this is considered two factors: Possession Factor plus Inherence or Knowledge.

Additionally, FIDO authentication is phishing resistant.

[bsimic0001]

@rlin1's point is a very important one. I would even venture to say that perhaps the column should be called "Phishing Resistant MFA" since there are many common tools such as Modlishka that can bypass authentication that requires user input or is not initiated by the individual.

[Carlgo11]

Hi again,
can anyone here confirm that a key (knowledge or biometrics based) to the private key on the authentication device is required in the current FIDO2 specification?

If we are to list all FIDO2-supporting sites as 2FA they would all need to require User Verification as we have no process of inspecting the implementation on each site.

[jgrantindc]

Yes, all FIDO2 implementations require some sort of user verification - either a biometric or knowledge factor matched locally in the authenticator. NIST refers to these as Multifactor Cryptographic Authenticators. They can be implemented in both hardware and software. One potential exception: some FIDO security keys, which only require user presence to be confirmed - i.e., touching a Yubikey. In those cases they are designed to be used as a standalone second factor alongside another factor such as a password. NIST calls these Single Factor Cryptographic Authenticators and requires they be used to augment a knowledge factor. Sites that support FIDO2 automatically support both - and can tell if an authenticator is single or multi factor through the authenticator’s attestation certificate. Happy to answer additional questions if helpful. Jeremy

[Carlgo11]

Thank you Jeremy!
I do have follow up questions if you have the time.

Sites that support FIDO2 automatically support both

Does that mean all sites that support FIDO2 have to implement a prompt for password in the case UV isn't available?

Are there any ways of independently verify UV is required? We receive a lot of requests to add new sites and very often the sites wanting to be listed don't actually support 2FA but some version of 2SV. I can imagine verifying FIDO UV-enforcement could be tricky for us.

Lastly, just out of curiosity, what stops a FIDO2 device from lying about user verification? I can imagine cheap devices just treating UP as UV. Like a Yubikey Biometrics key on Wish 😅

[jgrantindc]

Looping in David Turner - who leads technical and standards work for FIDO Alliance - to answer these. FIDO’s certification program addresses some of these issues - there are 900+ FIDO certified products that have all gone through conformance testing. On Jan 11, 2023, at 10:00 PM, Carlgo11 ***@***.***> wrote:  Thank you Jeremy! I do have follow up questions if you have the time. Sites that support FIDO2 automatically support both Does that mean all sites that support FIDO2 have to implement a prompt for password if UV isn't available? Are there any ways of independently verify UV is required? We receive a lot of requests to add new sites and very often the sites wanting to be listed don't actually support 2FA but some version of 2SV. I can imagine verifying FIDO UV-enforcement could be tricky for us. Lastly, just out of curiosity, what stops a FIDO2 device from lying about user verification? I can imagine cheap devices just treating UP as UV. Like a Yubikey Biometrics key on Wish 😅 — Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2F2factorauth%2Ftwofactorauth%2Fissues%2F6388%23issuecomment-1379749395&data=05%7C01%7C%7C691c7a2909d84e15e0f908daf44919f9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638090892056960111%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OBx%2B%2FtkjQKZE64o%2BPFSWlU3WPKj%2BwUh97xAgKxc99Xc%3D&reserved=0>, or unsubscribe<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAEOXS3QHDQJRKTT6GQBAGVLWR5XTFANCNFSM5LGLQOEA&data=05%7C01%7C%7C691c7a2909d84e15e0f908daf44919f9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638090892056960111%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dXyobXZ4lXS4v5Rh3YcF7V%2FCNO58UuiRdiF7G6aBRuM%3D&reserved=0>. You are receiving this because you commented.Message ID: ***@***.***>

[ChristianTacke]

Just my 2ct: I think that non standard keys should be outside the scope of 2fa.directory. If a potential website does all stuff 100% correctly, then it should be listed in the proper category. They can't fix non-standard FIDO keys.

[jgrantindc]

Yeah, this gets into a level of implementation detail that is going to be hard to address. FIDO is a freely available standard and if someone wants to build their own authenticator and not get it certified, it still has the value of being a phishing resistant authenticator (unless someone did an awful job). I can do the same with TOTP, no site is going to ban me from using that homegrown authenticator. What should matter is if they support the standard. Also on the previous point: I’d say that a single factor security key login (without a biometric or PIN verification, just touch) is in most cases more secure than a most legacy 2FA. In that it’s still a phishing resistant login that would require me to get physical possession of your key to compromise. There is no way to execute a remote attack. So while it is not best practice to implement a single factor security key without a second factor, it’s still a lot better than other authentication alternatives. On Jan 12, 2023, at 8:09 AM, Christian Tacke ***@***.***> wrote:  Just my 2ct: I think that non standard keys should be outside the scope of 2fa.directory. If a potential website does all stuff 100% correctly, then it should be listed in the proper category. They can't fix non-standard FIDO keys. — Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2F2factorauth%2Ftwofactorauth%2Fissues%2F6388%23issuecomment-1380323526&data=05%7C01%7C%7C6e7951296f01452d139908daf49e3a63%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638091257670328294%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9yE%2FLAZljHbfdgdY9PkS5yHyAEt6rBPoaigUWKmen%2Bk%3D&reserved=0>, or unsubscribe<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAEOXS3VSO725MPMW5WPHDZTWR77AHANCNFSM5LGLQOEA&data=05%7C01%7C%7C6e7951296f01452d139908daf49e3a63%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638091257670328294%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pN04viRP%2FD62K28ETzEDk0Jb7Q5de1sQbtEmP9JUNWs%3D&reserved=0>. You are receiving this because you commented.Message ID: ***@***.***>

[Carlgo11]

The question about key capability verification was just out of my own curiosity.

The main question in regards to this thread is how we can interrogate a FIDO server and verify the capabilities and requirements for authenticating with the server.
It would need to work independent of server-implementations and without requiring physical keys as we can't use that in GitHub workflows.

Any code examples are welcome!

Alternatively, if the FIDO Alliance provides a list certified/compliant servers we could feed that directly into the site and not have to manually validate anything.

[brandongalbraith]

@Carlgo11 I don't believe, at this time, there is a discovery mechanism for a site to advertise what webauthn/FIDO2 capabilities are supported (I suppose there is an opportunity for someone to register a well known URI to support this).

https://passkeys.directory/ ("Websites, apps and services using passkeys for authentication") is manually curated, for example, and requires evidence be provided that the site does indeed support passkeys: https://docs.google.com/forms/d/e/1FAIpQLSfsTxXH0jWA3Op4Qbte3tdn2OR0zs8ixLKljWswSI-Gi3V80A/viewform

[Carlgo11]

Thanks for the info @brandongalbraith 👍
I'll forward it to the rest of the org and we'll see if it's possible for us to do something similar to passkeys.directory.

[ChristianTacke]

How ever this gets implemented, please also provide a way to filter/search for those entries. Like one can currently filter on 2fa:u2f.

[gbdlin]

The question about key capability verification was just out of my own curiosity.

The main question in regards to this thread is how we can interrogate a FIDO server and verify the capabilities and requirements for authenticating with the server. It would need to work independent of server-implementations and without requiring physical keys as we can't use that in GitHub workflows.

Any code examples are welcome!

Alternatively, if the FIDO Alliance provides a list certified/compliant servers we could feed that directly into the site and not have to manually validate anything.

There is a way to test that - trying to register a security key on such device with user verification disabled. It can also be disabled in the browser on some platforms - for example Firefox on Linux with security.webauthn.ctap2 disabled in about:config will not support user verification via PIN (biometrics may still be supported, I can't test it, but getting a token that doesn't support biometrics should solve it).

For attestation, you can "break" it by anonymizing the response from the hardware token, which is also supported by Firefox on Linux. This way you can also check if specific website only accepts certified devices for passwordless login.

I think this should be a good enough procedure, if it's possible to be implemented, for making sure passwordless logins for websites are still 2FA. Some security key emulation software may also be used for such purpose.

Given that, I'd like to ask for another use case, if it can be considered 2FA still: my government offers logging in using a secure element embedded in my ID. This still requires providing a valid PIN to unlock this secure element. Can it be added as a custom hardware 2FA method?

[Carlgo11]

Hi all,
I wanted to update you on the recent development regarding your request for passwordless options on the 2FA Directory.

Instead of adding a column for passwordless authentication within the existing framework, we've decided to create a new directory dedicated solely to passkey support. You can find it here.

Passkey authentication offers a unique approach to user security, significantly different from conventional authentication methods. Listing passkey authentication alongside traditional MFA options in the current directory, we feel, wouldn't accurately represent its unique characteristics.

We would appreciate your thoughts on this decision. Please feel free to explore the new directory and share your opinions with me. Contributions to the list are also very much appreciated!

[brandongalbraith]

This sounds like a reasonable approach, comparable to the directory 1password hosts at https://passkeys.directory/

Great path forward 👍

[Carlgo11]

Thanks. We did enquire Agilebits/1Password about taking over their passkeys.directory as it seems less maintained and considerably smaller in size, but at the moment, the two sites are separate.

[JohnLGalt]

That last part is what I was going to suggest lol. Good to know you've already made inquiries, and thank you for starting your own passkey-enabled site list. I hope the merger of the two sites comes about amicably, I think it would really take a load off them.

[hex-m]

Passkey authentication offers a unique approach to user security

I see a lot of confusion about what Passkey actually means so I'd like to share my understanding and see if we agree. I assume when you say passkey you mean "passwordless". Technically speaking that would mean discoverable webauthn-credentials with userVerification enabled (they may be device bound or synced). The same credential could be used either as a second factor (also asking for username and password) or as a passkey (where there is no field to enter the username anymore but "Autofill UI").

Here is another list of websites that implemented it: https://passkeys.dev/docs/demos-examples/active-deployments/

[gbdlin]

I want to add one thing: passwordless and discoverable doesn't need to go together. Discoverable means more of a "logilness" that is website can ask your device what accounts it has in store (and show the list of them to use, if needed) instead of asking user to provide the full login. Non-discoverable credentials can also be used without a password.