In theory the passkey concept was created to not require email + password strategy making password unnecessary and email optional just like 2FA, so firstly by following it we should be aware that the email is at most optional field during registration, but most probably it could be even a part of additional profile/user settings - again just like 2FA.
In theory there should be no problem with implementing lost passkey page, but in practice I can imagine a case when email account is stolen. Since we have no idea about email account security we can’t assume that’s a good source of truth. The simplest example here are temporary email accounts where you just have to type an alias name and yeah, that could happen also with email + password strategy.
So what could be done in such case? I believe a proper implementation would be a requirement of at least one 2FA method in case a user decides to set an optional email field which is part of profile/user settings available after registration.
As an alternative you could implement multiple devices support. In such case a the lost passkey page only needs a PIN or QR Code support, so the user could replace the passkey using other device. This strategy is much better since it does not require email. If lost passkey page uses LiveView or WebSocket there should be no way to steal your account even if somebody would notice a PIN / QR Code as it could be easily assigned only to the specific WebSocket client and any new attempt would generate another one. Somebody may say that in such case the account could be stolen anyway by other PIN / QR Code as long as attacker have a vision of your other device screen, but in practice a simple confirmation dialog before it prevents such attacks.
The only possible problem here is what to do if there are 2+ requests in similar time. First of all such case should be very rare. A simple information box to not reset passkey in public place could be more than enough, but there are other possibilities. One of them is to simply block lost passkey page for some time if there are 2 requests in short amount o time. The user could simply restore their account just 1 hour later or so. However much better way is to generate said PIN on 2 devices. As long as the attacker does not have access to your second device your account is secure.
While it is theoretically true that “email” is not required, the docs say
this is often a practical requirement for both a business and its users. By requiring an email, WebauthnComponents ensures each registered Passkey can be identified by the user when reviewing their collection of credentials. Email is often a required identifier for a business, especially when it needs to communicate with its users outside of its applications.
I agree with this. Moreover, I feel that most users assume that they should be able to “reset” their credentials, so long as they have their email.
I think that requiring multiple devices alienates a lot of users, especially users living near or below the poverty line, who never have more than one device, usually an old smartphone. Old devices cannot support WebAuthn so I would ideally support email+password as a fallback auth mechanism.
Your system of multiple devices + 2FA is extremely robust and secure. However, am I correct to think that if both of the users devices are, say, stolen from them, then they have no way to access their account?
I’m currently using email. I like the idea of backup codes — maybe I’ll implement that as an option for people who trust that they won’t lose their backup code.
Are you using WebAuthn? If so, when a user signs in on a new device with an existing email, do you automatically sign them in as the existing user?
I know there is a flow for “I already have an account” which requires authenticating using a pre-existing device. I am interested in the case of a user with 1 device only who loses their passkey.
Hey @slouchpie! After a quick skim of the original post, I’d say it’s best to establish backup methods when an account is created and when a passkey is added. That could mean generating backup codes or encouraging registration of a second passkey or other auth method.
With the vulnerabilities of SMS, email, and OTP codes, and the unfamiliarity of Passkeys, it’s not always an easy choice. It really depends on the threat model of the application and its users.
Ideally, the user could register two passkeys, which would provide the most security. Practically, that may be complicated. WebauthnComponents doesn’t yet have examples for registering additional passkeys, but it could be implemented manually by following the example code. Secondary key registration is something I will tackle eventually if there hasn’t been a contribution from the community.
I may follow up in more detail later, but that’s hopefully informative.
That aligns with my thinking too. I am moving forward with “email as identification”.
For additional passkeys - this is not too difficult to implement using what has already been generated. I was glad that the generated code was concise enough to review in its entirety relatively quickly.
Yes, I’m using WebAuthn. When a user signs in on a new device, they are sent a one time code ([ab]using NimbleTOTP) just like when they signed up in the first place.
In the database, we allow multiple passkeys per user. This allows users to log in from multiple computers even if they can’t share passcodes between computers, and also allows users to delete all their passcodes and still be able to log in. When building the passkey flow, I created a lot of passkeys on my computer so it was really nice to be able to delete them all and still be able to log back in.
For one of my apps that uses passkeys, all users must supply an email address because there are a number of email-based workflows. In another app, email is not heavily used, so I like the idea of using backup codes and allowing users to not ever give us an email address.
Sorry for the necro but I have been working on the WebAuthn integration in my own project and I have some concrete principles for the future auth system. Sharing them here for posterity.
Users need a unique, confirmed email. The “just passkeys” approach is valid but almost everyone has an Apple/Google device, which means an Apple/Google account, which means an email.
Put each “flow” in its own LiveVIew (same as phx.gen.auth)
Let the users decide if their email can be used for recovery.
Let the users decide if backup codes can be used for recovery.
Loudly tell the user if they have no recovery mechanism in place, prompt them to allow email recovery (this is just for my system, other apps will have different priorities).
Let users manage their keys. I am considering how to add helpful info to them. I am already parsing the user agent with UAInspector so I might just use that. This should allow “create passkey”.
If user signs in using “sign in with a different device” flow - can this be detected? Presumably yes. If so, prompt them to visit “manage keys” view with “create key on current device” action.
