mirror of
https://github.com/pocket-id/pocket-id.git
synced 2026-02-05 00:39:38 +03:00
🚀 Feature: MFA #249
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @RealOrangeOne on GitHub (Apr 16, 2025).
Feature description
Whilst passkeys are great, and they're significantly better than username/password, they're not implicitly multi-factor.
Adding a second factor, such as conventional TOTP, adds an additional level of protection for those using passkeys.
Pitch
Many vendors, such as Apple, implement Passkeys in a way which requires MFA (on device and biometrics), it's not always the case (for example, using a Yubikey).
Adding a second factor (opt-in, of course) adds an additional level of security, regardless of whether the Passkey itself is protected with MFA.
@savely-krasovsky commented on GitHub (Apr 16, 2025):
CTAP2 (aka FIDO2) was explicitly developed to eliminate the need in both password and OTP. By spec it requires explicit consent and verification (either PIN, biometry or other method). It proves that you have an access to passkey storage and then checks your authorization again. This is exactly what password+OTP pair does: access to PIN/biometry and your authorization using passkey which replaces OTP (this is exactly why CTAP1 (aka U2F) replaced OTP when it was alive).
In case of Yubikey PIN is your first factor and passkey itself is a second factor. You cannot add non-residential passkey as far as I am aware (which is not requiring PIN). If it allows--it's a bug.
Overall I am strictly against adding any other 2FA to not over-complicate things.
@kmendell commented on GitHub (Apr 17, 2025):
@savely-krasovsky Yes, you are right in your point, i talked with Elias before i added the upvote label. We don't see a need to add this just as a outright additional feature (put simplily) but are keeping it open to see if someone had a legitimate need or use case for this for now.
@kmendell commented on GitHub (May 7, 2025):
I'm closing this issue, as MFA is not needed with passkeys and defeats the purpose of the spec. If there is a legitimate use for this, feel free to reopen this issue.
@kosli commented on GitHub (Aug 8, 2025):
Whereas I agree that passkeys are already protected by some kind of second factor itself, it is getting more common to have password managers in the browser that store the passkey (and syncs it with multiple devices) and is kept "unlocked" as long as the browser is open, by default. So it would still make sense for e.g. admin accounts to have an additional layer of security by an (external) 2FA, e.g. TOTP generated on the mobile in a separate app.
Another option is to have the application itself, e.g. paperless, ask for the 2FA, but that makes it more complicated as the (admin) user will have 2FA per application, instead of the SSO experience with a single 2FA.
I hope there are other users agreeing on having 2FA and upvoting this ;-)
btw, thanks for this great tool!
the only thing that prevents me currently for using it in preference of authelia is the 2FA.
@savely-krasovsky commented on GitHub (Aug 8, 2025):
@kosli IMO it's entirely the password managers’ problem. I understand your point, but we shouldn’t mitigate risks caused by passkey provider implementations. The FIDO2 specifications clearly state that it’s the job of the hardware token or the platform/sync passkey provider to implement those security measures, not the relying party (which we are).
You should also understand that FIDO2 was designed to be a truly passwordless solution, which includes replacing 2FA codes. That’s why you can sign in to sites like Binance or Google and bypass 2FA when using passkeys. Unfortunately, password managers undermine those efforts by providing less secure ways to use passkeys, but instead of trying to add “better security” on our side, I would push Bitwarden and other managers to fix this issue.
By the way, AFAIK, Bitwarden acknowledged the problem long ago (since the introduction of the passkey feature), but since then they haven’t done anything to fix it or provide proper user presence/verification logic.
@savely-krasovsky commented on GitHub (Aug 8, 2025):
I would work in other direction if you want to improve passkey security: allow to use only some AAGUID for certain clients. For example I want to allow authorization only from Yubikey. Then I would add only theirs AAGUIDs and check attestation certificate chain using public key from MDS (FIDO Alliance Metadata Service) at Pocket-ID side. In this case I would have 100% verification that Yubikey was used and not Bitwarden.
@lordraiden commented on GitHub (Aug 29, 2025):
Here there is an argument to reconsider this and the use cases
https://github.com/pocket-id/pocket-id/issues/895#issuecomment-3236305390