Following up on Support passwordless login with Passkeys and a few weeks of internal testing, we are happy to announce that support for passkeys has now landed in Discourse.
What are passkeys
Passkeys are a safer, simpler alternative to using passwords for authentication. Creating and using a passkey is now widely supported across platforms and browsers. Compared to passwords, passkeys have better built-in safety due to strong platform-generated credentials and biometric identity validation (like touchID, faceID, PIN or device password). Passkeys are also safe from server-side leaks (the private portion of the key never leaves the device) or phishing (each key is linked with one website/service only).
Feature Rollout
If you are a hosted customer, passkeys support will be rolled out to your instance over the next few days. If you’d like to enable them right now, please reach out to @team here on meta or via email to team@discourse.org.
If you are self-hosting Discourse, note that the feature will be enabled by default in Discourse core shortly is now enabled by default in core as of this commit. If you would like to disable it, you can do so via the Rails console:
launcher enter app
rails c
SiteSetting.enable_passkeys = false
Note that passkeys can only be used on Discourse instances with local logins enabled. If your instance doesn’t use local logins, the passkeys feature has no effect.
Once the feature is enabled, users can add passkeys to their account by going to the security tab of their user preferences:
Once a passkey is registered, they can login with it via the autofill dropdown under the username field (1) or by clicking on the “Login with a passkey” button (2).
Once the initial rollout of the feature is complete, we may consider making the following improvements:
Allow setting up a passkey on account creation
Allow passkeys to be used when confirming sensitive actions (currently supported in the Security tab of User Preferences but not in some admin-only screens)
Allow removing passwords altogether (on a per-user or per-instance basis?)
This is a great addition! However, the security benefits can be easily bypassed by logging in with a password. I expected to still be prompted for a passkey after entering my password, but it just logs in with the password. This can be avoided by reregistering the security keys in the separate 2FA settings, but that’s not obvious and is cumbersome.
In most current implementations, passkeys aren’t yet being deployed this way. They’re being treated as independent from 2FA, see this report on Youtube’s approach. I think the industry will slowly adapt here though.
There are two changes needed for this to work as you expect:
step 1: allow using passkeys as 2FA (currently, as you noted, security keys need to be registered independently)
step 2: enforce 2FA on password logins when user has added a passkey
Step 1 makes sense to me, and it’s not disruptive. Step 2 makes sense too, but it is a little disruptive, if user deletes the passkey from their browser (or doesn’t have it on a given device), access will be blocked.
I think Firefox is actively working on adding passkeys support across the board, but it’s still not 100% there if I am reading this chart correctly.
Depending on your version and operating system, it might not yet be available. I just did a quick test on macOS and iOS, and passkey authentication was available and functional for me here on meta.discourse.org.
You can write a PM to @team here or send an email to team@discourse.org and we can disable this feature for you. We don’t recommend doing so, many services on the web are adopting passkeys as a safer option for authentication.
Is it in the plans to eventually be able to disable the password altogether (preferably on an account setting basis, I can see forcing entire sites to do it not ending well)? Because having both a passkey and a password active kind of limits the usefulness of the passkey. You can sort of mitigate it by making a stupidly complex password and just never using it but that’s just sidestepping the point of passkeys
If I understand the passkey mechanism correctly, you need to have installed a trusted container such as a password manager to store the access keys. Getting rid of passwords assumes that all users have installed such a manager, so how those users who did not do so will login?
The same way people who don’t use 2FA access sites that require 2FA - they don’t.
Not that this is an actual concern since Chrome, Safari, Windows, iPhones, Android, Yubi, etc. are all alternative to password managers (which you should already be using in 2024 regardless) and all function with passkeys.
I also wasn’t suggesting forcing every user to not have a password (though I’m fine with that) but if YOU the passkey user can’t disable your password then the passkey serves far less of a purpose and you’re still completely phishable.
If I chose passkeys for Discourse, I will not use anymore my password, so how can I be phishable ? I understand the risk of malicious or brute force attack on the password login will remain, and your suggestion to disable it per user is valid, but not by phishing?
Any updates on possibly supporting account creation with only passkeys and no password? Seems almost pointless supporting passkeys when you’re required to have a password anyway.
