Open mitar opened 1 year ago
Thank you for the idea! We have also been thinking about this but habe decided against it for thr following reasons:
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 :)
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.
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.
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?
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?
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.
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 :)
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.
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
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 🙏✌️
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.
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.
I do not think e-mail is necessary here. I can see this as multi-step registration process:
Login flow is the same:
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.
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):
continueSettingsFlow
works to mimic it during self-service account creation. Add another 4x effort for writing the tests.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....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.
Preflight checklist
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