slouchpie
Webauthn - what to do for lost passkeys?
I am experimenting with GitHub - liveshowy/webauthn_components: WebauthnComponents allows Phoenix developers to quickly add passwordless authentication to LiveView applications. · GitHub
I am wondering what to do when a user loses their passkey. Here is what I think should happen:
- “Lost passkey” button which un-hides an email input.
- Send a “create new passkey” email with some kind of link with a token
- Much like the process by which an email is confirmed, handle the “create new passkey” link in a controller and create a passkey if the token is right
- Upon successful passkey creation, login user and redirect to, say, home.
Does this sound right? @type1fool you are probably the best person to ask about this.
Marked As Solved
type1fool
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.
Also Liked
slouchpie
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
UAInspectorso 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.
The best-laid plans, etc.
eahanson
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.
type1fool
Shout out to @slouchpie for making some valuable contributions over the past few weeks!
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








