1

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:

The image shows a computer screen displaying a login modal with various sign-in options including social and service provider logins, as well as traditional email/username and password fields.
The image shows a computer screen displaying a login modal with various sign-in options including social and service provider logins, as well as traditional email/username and password fields.2174×910 70.5 KB

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).

The image shows a computer screen displaying a login modal with various sign-in options including social and service provider logins, as well as traditional email/username and password fields.
The image shows a computer screen displaying a login modal with various sign-in options including social and service provider logins, as well as traditional email/username and password fields.2034×1316 276 KB

More details

There are numerous resources and guides available on passkeys. I have found the following to be the most useful:

Possible future improvements

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?)
30 Likes
2

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.

3 Likes
3

Thanks @Be0

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 it makes sense to look into this, though.

7 Likes
4

Hi, when browsing my Discourse site on mobile (Firefox), passkeys are not supported, is it as intended?

4 Likes
5

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.

5 Likes
6

A post was split to a new topic: Issues using passkeys with vaultwarden

8

If the browser’s autocomplete function doesn’t include the passkey for some reason, you can click the “Log in with a passkey” button.

image
image1552×1056 122 KB

3 Likes
10

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.

4 Likes
11

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

4 Likes
12

Yes, I think that would be nice (and improved security for the account). Adding it now under the “Possible future improvements” section of the OP.

3 Likes
13

This is crucial to the safety of passkeys. They’re little more than a convenience if I can’t disable password login.

2 Likes
14

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?

1 Like
15

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.

1 Like
16

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?

1 Like