TOTP and lookup secrets as first factor authentication

[mitar]

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

I am trying to use Kratos for accounts without e-mail address or phone number, just username and password. The issue is how to recover such accounts. Currently it seems to me that this is not possible because recovery uses e-mail.

Describe your ideal solution

I think it would be great if TOTP could be used as the first factor instead of the password, and then lookup secrets as a recovery for failed TOTP, too. In combination with second factor (e.g., WebAuthn) that I think could still be pretty secure.

I find this also nice as a potential preferred flow to suggest to users who do not have e-mail address or phone number: setup password and TOTP and use TOTP as primary way to authenticate (e.g., use an app to fill those in). On devices which lack your TOTP-configured app, you can then enter your password.

Workarounds or alternatives

It seems the only alternative for accounts without e-mail address and phone number is to go with passwordless WebAuthn as the first factor and TOTP as the second factor (and lookup secrets as backup). But having password as the first does not leave much options for recovery.

Version

v0.11.0

Additional Context

No response

[aeneasr]

Thank you for the idea! We have also been thinking about this but habe decided against it for thr following reasons:

• TOTP is not a valid first factor mechanism according to NIST Digital Identity Guidelines
• No major vendor offers TOTP as a first factor
• No best practices around first factor TOTP exist

To reduce the number of decisions around security profiles and implications we decided to just stick to what NIST recommends. That way we are on a publicly reviewed standards process with state of the art security research :)

Thus, TOTP won’t be added as a first factor unless the guidelines change :)

[mitar]

TOTP is not a valid first factor mechanism according to NIST Digital Identity Guidelines

What? It is listed in "Table 4-1 AAL Summary of Requirements" under AAL1 as "SF OTP Device". For AAL1 it is listed also in section "4.1.1 Permitted Authenticator Type" as "Single-Factor One-Time Password (OTP) Device". It is further described in Section 5.1.4, where in 5.1.4.2 it explicitly mentions RFC 6238, a TOTP RFC. So TOTP is by my reading a valid single factor mechanism.

Does this make it also a valid first factor? For AAL2 it does require (in section 4.2.1) that one factor should be a Memorized Secret authenticator when combining with another single-factor authenticator. But if we read this strictly, we then have a problem that Kratos then does not support any password recovery mechanism which would be a valid AAL2. If you forget a password, then you cannot use a Memorized Secret, so you could not use Out-of-Band Device (e-mail link recovery) for account recovery either (which is currently default). Only multi-factor WebAuthn might be the only one which would satisfy AAL2.

So given that TOTP is a valid single factor mechanism and given that Kratos already allows another single factor mechanism (Out-of-Band Device) as the first factor mechanism (while NIST does not do so), I would say there is not much reason not to make TOTP the first factor as well.

Same reasoning holds for Look-up Secrets.

[aeneasr]

My bad, I should re-read the sources i cite instead of recalling them from memory. It's true that TOTP is a single factor and can be used as such according to NIST. It's an exotic use case (I have never encountered OTP as a single factor login method ever). From a priorities stand point, we have important things to improve such as mobile APIs, passwordless login with common methods like OTP / magic link over email, improved WebAuthn support, etc and no capacity to work on edge case scenarios. It's true that email and VOIP is not acceptable according to NIST:

The out-of-band device SHOULD be uniquely addressable and communication over the secondary channel SHALL be encrypted unless sent via the public switched telephone network (PSTN). For additional authenticator requirements specific to the PSTN, see Section 5.1.3.3. Methods that do not prove possession of a specific device, such as voice-over-IP (VOIP) or email, SHALL NOT be used for out-of-band authentication.

But it's such a common use case that there is a tremendous demand from customers in delivering this feature set, which is why it's a high priority on our roadmap. Unfortunately, SMS based OTP is also on the roadmap, due to popular/commercial demand.

In summary: I should not have used NIST as a lazy excuse not to do SF OTP for AAL1 :) We won't be able to prioritize SF OTP for AAL1 unless there is significant demand for such a feature and clarity around the user experience and account recovery, as well as implications for how recovery and AAL2 is solved.

[mitar]

So for me TOTP as a single factor is a recovery mechanism for forgotten password where user does not have some other e-mail address or phone number. So for me I would offer user or to pick a password, or to recover the account using TOTP (or recovery code). So the recovery for TOTP as single factor is for me the password itself or recovery code.

Is this something you would be open to a community contribution?

[kmherrmann]

To me, this can make sense as an optional setup. For my understanding:

• do you have email addresses on file? Do you offer a way to recover usernames if users forgot theirs?
• do you also use TOTP for MFA/AAL2 in combination with passwords, or would you only ask people to set up an authenticator app (or so) for the sole purpose of recovery?

[mitar]

do you have email addresses on file? Do you offer a way to recover usernames if users forgot theirs?

So users can decide to register with e-mail address, username, or username + add e-mail address later. Only in the second case I have a problem that I cannot use e-mail address for recovery. I do want to support the second case so that users are not required to have an existing e-mail address. And no, if they forget the username there will be no way to recover the username, but if they worry about that, they can add more recovery mechanisms (like e-mail, or security key). So users will be encouraged to add multiple recovery mechanisms.

do you also use TOTP for MFA/AAL2 in combination with passwords, or would you only ask people to set up an authenticator app (or so) for the sole purpose of recovery?

My (ideal) plan is that they can setup both TOTP, lookup secrets, e-mail address, webauthn, password, Facebook, Google, Apple for their account and be able to configure for which factor (1st, 2nd, or both) they can be used. So they could have TOTP for 1st factor and then security key for the second, for example. TOTP, lookup secrets, password, and recovery code require one to provide username/e-mail to be used as 1st factor.

[kmherrmann]

Thank you! We had more discussions internally here, and lean towards allowing Webauthn as either 1st or 2nd faster, but not allow 2x Webauthn as a "MFA" login. Stay tuned :)

[lucasff]

We have a use case that is passwordless. The identifier is either the email or password, and the TOTP sent through SMS or email is the verification itself. We would like to completely kill the password.

[github-actions[bot]]

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas on how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan for resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneously you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️

[jacwil]

I've been brainstorming how to get TOTP bootstrapped as a replacement for passwords. Specifically I've been thinking of invitation emails containing the QR code and TOTP secret so user can setup their authenticator app, and for self-service account creation maybe require TOTP setup during first sign-in, or if email verification is enabled make TOTP setup a required step during email verification: "Congrats! You verified your email. Now setup TOTP so that you can sign-in."

If the user needs to reset their TOTP because maybe they lost their phone, maybe resending the invitation email or resetting the email verification flag in addition to clearing the TOTP url's so user has to go through setup flows again.

[jacwil]

I would like to contribute towards making TOTP a first factor authentication. I'm trying to make sense of the flows in the source at the moment. My strategy is figuring out how to send QR codes for TOTP setup with the email verification message as a first step to enabling this feature.

[mitar]

I do not think e-mail is necessary here. I can see this as multi-step registration process:

• User enters their e-mail address or username and click next.
• On the next page you show them QE code and TOTP secret and prompt them to enter TOTP.
• If they manage to enter a correct TOTP, they are registered.

Login flow is the same:

• User enters their e-mail address or username and click next.
• You prompt them to enter TOTP.
• If they manage to enter a correct TOTP, they are logged in.

You can tie this to e-mail verification, but I think it is not necessary. E-mail verification can be done in parallel with e-mail and code there for e-mail verification itself.

[jacwil]

Well I underestimated the non-trivialness of this feature by a couple of orders of magnitude. Definitely not something I can make any worthwhile progress on over weekends. As my read of the code and experimentations are (which are likely to be wrong so happy to hear different):

1. TOTP needs a Registration Flow for this feature. As I'm not a web developer its going to take some time and experimentation for how continueSettingsFlow works to mimic it during self-service account creation. Add another 4x effort for writing the tests.
2. I thought I'd start with the above, but its becoming apparent I'm missing some important prerequisites to triggering a Registration Flow for TOTP beyond the obvious identity.schema.json accepting totp in the credentials section and adding registration to the schema. When I start Kratos with password auth disabled I was greeted with no options for account creation.
3. TOTP is codes as AAL2 in Kratos as aeneasr already mentioned, which implies it is not setup to be the primary identity (AAL1?). What this seems to mean is that if you downgrade TOTP to AAL1, you cannot use it as AAL2. Maybe that's what aeneasr was alluding to in the final comment:

   ...as well as implications for how recovery and AAL2 is solved.

I see still see this feature as possible in Kratos but not viable from a business perspective to justify the investment nor is there a pressing business case unless other IAM providers shift in that direction first.

The fluid movement of TOTP between AAL1 and AAL2 is not possible today in Kratos. A design would first have to be proposed and implemented to include additional metadata to make a decision if a user's current settings meet AAL2 criteria or not. I'm reading that this is the major blocker for any acceptance of this feature. Even if functioning registration and login flows were to be coded and contributed organically from the community, I expect it to be never be accepted for merge until Kratos understands TOTP doesn't guarantee AAL2.

For recovery in such a setup I'm failing to see how it would be much different than password other: send the user a new TOTP source url and QR image, maybe unlinking any existing TOTP or maybe preserve the old ones and let the user decide to unlink. But discussing recovery is moot at the moment. Just mentioning it because its a valid concern but not something I see as an issue for self hosted.