If password-less sign-up is enabled: allow user to choose if webauth should complement an existing password as aal1 or act as aal2

[MiniDigger]

Preflight checklist

• [X] I could not find a solution in the existing issues, docs, nor discussions.
• [X] I agree to follow this project's Code of Conduct.
• [X] I have read and am following this repository's Contribution Guidelines.
• [ ] This issue affects my Ory Network project.
• [X] I have joined the Ory Community Slack.
• [ ] I am signed up to the Ory Security Patch Newsletter.

Describe your problem

This issue is similar to #2794.

I have an instance where users get to choose between password and password-less sign-up (providing the extra security for those who want, without annoying others too much).

I allow adding TOTP, backup codes and security keys/webauthn as second factors, but since I enabled password-less sign-up, webauthn no longer is treated as second factor, even tho it is a second factor when password is your first factor.

Describe your ideal solution

Kratos should detect if the first factor was password and treat webauthn as second factor, even if password-less signup is enabled.

If password-less is enabled and first factor was webauthn, adding another webauthn key should only increase the factor for the reasons outlined in #2794 (before that is implemented, not all at).

Workarounds or alternatives

Discarding usage of the aal kratos gives me and checking the lists of methods manually, basically ignoring all aal handling in kratos.

(I don't even know if I can get the list of configured methods for a user nicely and securly)

Version

v0.11.0

Additional Context

No response

[MiniDigger]

actually, thinking more about this, what I actually want is allowing the user to choose if webauthn replaces/complements aal1 or acts as aal2

[woylie]

If password-less is enabled and first factor was webauthn, adding another webauthn key should only increase the factor for the reasons outlined in #2794 (before that is implemented, not all at).

Just to clarify, #2794 is about Webauthn devices that combine two factors in a single device. Adding a second Webauthn device does not count as a second factor (it might if the second device adds a biometric scanner, but in that case, the second device already has two factors, making the first device redundant).

[woylie]

That being said, allowing the user to use Webauthn as either the first (and potentially only) factor or the second factor would be a nice feature to have.

[MiniDigger]

Just to clarify, #2794 is about Webauthn devices that combine two factors in a single device.

oh, that makes sense, thanks for the clarification. I just woke up so excuse me figuring out the actual feature request while I was opening the issue ^^

[aeneasr]

We’ve been thinking about this a lot during implementation. The problem of using one factor as either first or second in context of other authentication mechanisms is brittle. It’s also confusing from the user experience. Why can’t i use finger prints for first and yubikey for second factor? From a security perspective it makes sense but from a user perspective not really. I think we’ll prefer an opinionated way of doing this (you can either have X or Y) to have clarity in terms of user experience:)

[kmherrmann]

Why can’t i use finger prints for first and yubikey for second factor? From a security perspective it makes sense but from a user perspective not really.

What makes you think so? FaceId/TouchId as password replacement for 1st factor is actually preferably, and then having a yubikey as second factor is natural in high-security settings.

It does make setup and the mental model more complex, but I think on webauthn and potentially OTP we need some flexibility of having them act as 1st or 2nd factor.

[aeneasr]

Because "TouchID" or "FaceID" or "Windows Hello" ,"Passkeys" are nothing we can explicitly request. You have two choices when triggering a WebAUthn flow:

• plattform (TPM, facebid, touchid, passkeys, could also be something else)
• crossplatform (e.g. yubikey - any yubikey, with fingerprint, without, ...)

source

In security, you have three factors:

• something you know (password)
• something you are (fingerprint)
• something you have (device)

Furthermore, NIST explicitly requires something you know (password) and something you have when you want 2FA derived from two one factor authenticators versus using a multi-factor authenticator:

• https://pages.nist.gov/800-63-3/sp800-63b.html#sec4
• https://pages.nist.gov/800-63-3/sp800-63b.html#sec5

At AAL2, authentication SHALL occur by the use of either a multi-factor authenticator or a combination of two single-factor authenticators. A multi-factor authenticator requires two factors to execute a single authentication event, such as a cryptographically-secure device with an integrated biometric sensor that is required to activate the device. Authenticator requirements are specified in Section 5.

When a multi-factor authenticator is used, any of the following MAY be used:

Multi-Factor OTP Device (Section 5.1.5) Multi-Factor Cryptographic Software (Section 5.1.8) Multi-Factor Cryptographic Device (Section 5.1.9) When a combination of two single-factor authenticators is used, it SHALL include a Memorized Secret authenticator (Section 5.1.1) and one possession-based (i.e., “something you have”) authenticator from the following list:

Look-Up Secret (Section 5.1.2) Out-of-Band Device (Section 5.1.3) Single-Factor OTP Device (Section 5.1.4) Single-Factor Cryptographic Software (Section 5.1.6) Single-Factor Cryptographic Device (Section 5.1.7)

While we do not need to follow NIST guidelines, they are there for a reason. Here's a simple example: using TouchID on your macbook. This implies:

1. you have the device (something you have)
2. you have the fingerprint (something you are)

which - if we do not follow NIST - would be considered a second factor. That's why it does not really make sense to use WebAuthn for both first and second factor:

1. We don't know which method was used (only can distinguish between platform and crossplatform)
2. We should require something you know + something you have for 2FA

So yeah, that's why we implemented this the way we implemented it. We can also remove the restriction, but it does come at a cost (security). We also couldn't really prevent users from:

1. Using fingerprint to set up 1st factor (on macbook)
2. Use passkey to set up 2nd factor (on same macbook...)

We could only do:

1. Use platform module to set up 1st factor
2. Use crossplatform module to set up 2nd factor

and hope that noone ever comes up with the idea to say "Windows hello is cross platform", which is explicitly mentioned in the WebAuthn spec:

An authenticator’s attachment modality could change over time. For example, a mobile phone might at one time only support platform attachment but later receive updates to support cross-platform attachment as well.

https://w3c.github.io/webauthn/#sctn-authenticator-attachment-modality

[aeneasr]

Interestingly, Hanko says:

User Verification: Required – This triggers the Authenticator to ask for Face ID, Touch ID or a PIN whenever the new passkey is to be used. Your device decides which mechanism is active. We want multi-factor authentication!

which I think is misleading:

Note that user verification does not give the Relying Party a concrete identification of the user, but when 2 or more ceremonies with user verification have been done with that credential it expresses that it was the same user that performed all of them. The same user might not always be the same natural person, however, if multiple natural persons share access to the same authenticator.

https://w3c.github.io/webauthn/#user-verification

I guess what they want to say is that we want user verification for the passkey. But I think that all platforms require touch/face/hello/... or some other user intreactions when unlocking a passkey

[mitar]

I think what this issue is about is that instance-wide configuration of password-less vs password-based authentication is not enough and that there should be per-used configuration. So if user is using a password as the first factor, then webauthn can be used as the second one. And if the user is not using a password, then webauthn could be used as the first factor and something else besides webauthn should be used as the second factor. Can we agree on this?

I think the difference in views here is then could webauthn be used by one user as both first and second factor and complexities of that and how to assure that they are of different kinds and that platform really cooperates correctly here. I think this is maybe for some other issue/feature request and it indeed seems tricky.

But let's make this issue only about the question if this configuration could be per-user. So if user sets up a password, they can use webauthn for second factor. If they have not setup a password, then they should not be able to use webauthn for both the first and the second factor.

[kmherrmann]

I'm not sure this has to be a per-user configuration. We can view it as a policy configuration, saying "you cannot use webauthn as 1st and 2nd factor in the same flow"*, or more generally, do you require 2FA or is 2-step-auth enough? A similar argument can be made about login with password + email OTP. if PW reset is possible via email, then this is just 2SA, which is less secure but still a valid option for businesses with less stringent security policies.

This way, you can avoid an annoying scenario where setting a password once rules out moving over to passkeys for 1st factor login.

*) I still believe it's entirely valid to log in with a passkey and then use an Authenticator App, Yubikey or 2nd device as 2nd factor. Actually, i think that's one of the best experiences for real MFA. Thus we'll continue to investigate if that's possible without accidentally turning it into 2SA.

CC /@hperl

[aptgetgit]

Not sure if this should be a separate issue, but seems to be similar so adding here.

There appears to be an issue with utilizing code as an identifier (via email) in a fully passwordless environment (with passwords disabled). Despite setting the required_aal configuration to highest_available for both settings and whoami flow and ensuring that Allow Login without Second Factor is disabled on the console, MFA is not being enforced when changing settings or using whoami. Even after adding TOTP and other MFA methods, session information clearly indicates an assurance level of AAL2. However, the configured rules are not being respected when accessing settings, whoami, or during login.

[kamilkloch]

2. We should require something you know + something you have for 2FA

"Binance now supports using passkeys to verify your identity for most account functions across different devices. Once you’ve added a passkey, you can use it for Two-factor Authentication (2FA) on all your linked devices. It enables faster and more secure verification to protect your account than simply using passwords."

https://www.binance.com/en/support/faq/how-to-create-a-passkey-for-my-binance-account-2aec8fe0437242f2a5fbef9cdb71d4c2