Webauthn and AAL2 - Githubissues

woylie commented 1 year ago

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 Cloud project.
[X] I have joined the Ory Community Slack.
[X] I am signed up to the Ory Security Patch Newsletter.

Describe your problem

We would like to require aal2, and in my understanding, a FIDO authenticator with a built-in biometrical challenge (e.g. Yubikey Bio, iPhone with face ID) would already fulfill the criteria for aal2. However, logging in with such a device when Webauthn is configured for passwordless authentication will only result in aal1.

Describe your ideal solution

At the moment, Webauthn can either be enabled as a second factor, or as a first factor instead of a password. In the latter case, Kratos will return aal1 when the user authenticates with a Webauthn device only. However, there are Webauthn devices with built-in biometric scanners. I believe these are called user-verifying platform authenticators in the specification. The RP can determine the user verification status by reading the UV flag in the authenticator data. So if I understand it correctly, Kratos should return aal2 if that UV flag is set to 1.

Workarounds or alternatives

None. Currently, a user needs to set up TOTP in addition to a user-verifying platform authenticator if 2fa is required.

Version

0.10.1

Additional Context

Moved from discussion: https://github.com/ory/kratos/discussions/2702

aeneasr commented 1 year ago

I think this is a great idea and possible to implement. Probably needs a few configuration settings. Testing will probably be a bit painful (you'll need to buy a yubikey capable of MFA and copy/paste the payloads or mock this somehow differently).

From our end it will probably take a while before this becomes part of the roadmap as there are many other things we need to resolve first.

woylie commented 1 year ago

Testing will probably be a bit painful (you'll need to buy a yubikey capable of MFA and copy/paste the payloads or mock this somehow differently).

If you happen to have a MacBook with a fingerprint scanner, you can use that. Apart from actual devices, there are some dev tools available:

aeneasr commented 1 year ago

Oh cool, the virtualwrbauthn package looks nice!

github-actions[bot] commented 6 months ago

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 🙏✌️

woylie commented 6 months ago

With the push towards passkeys in the industry, this has become even more relevant. I think this issue should stay open.

Sytten commented 6 months ago

Automatic issue closing is now considered bad practice. It just creates duplicate issues. This bot really should be removed.

mitar commented 6 months ago

is now considered bad practice

Any reference for this claim?

Sytten commented 6 months ago

is now considered bad practice

Any reference for this claim?

https://blog.benwinding.com/github-stale-bots/

https://drewdevault.com/2021/10/26/stalebot.html (HN: https://news.ycombinator.com/item?id=28998374)

https://ericswpark.com/blog/2022/2022-10-21-please-stop-using-the-stale-bot-incorrectly/

It is universally hated. Closing manually by maintainers for out of scope is fine, but closing based on some arbitrary time is just counterproductive.