As we're always wanting to keep ahead in the security game, I'm happy to announce that we now support Passkeys on Report URI! Let's take a quick look at what Passkeys are, why you should use them, and how we've implemented them.
Passkeys solve a big problem
Let's kick things off by stating the biggest benefit of Passkeys which is that they are phishing-resistant! That's right, if you're using Passkeys to protect your account, you no longer have to worry about falling victim to a phishing attack. This was the primary driver for us to add support at Report URI, to provide our customers with a strong authentication mechanism that will give them confidence they are protected against the pervasive threat of phishing attacks. On top of this tremendous benefit, I feel that they're also much more convenient to use too!
How do Passkeys work?
Instead of relying on a secret piece of information like a password, Passkeys work by relying on cryptography and are surprisingly simple under the hood. Your device will create a cryptographic key pair that will be used for authentication when you need to login to the website. The registration process for a Passkey looks like this:
User Browser / OS Website / Server
| | |
| 1. "Create Passkey" | |
|--------------------->| |
| | 2. Request registration |
| |-------------------------->|
| | |
| | 3. Send challenge |
| |<--------------------------|
| | |
| | 4. Create new key pair |
| | - save private key |
| | on device |
| | |
| | 5. Send public key + attestation
| |-------------------------->|
| | | 7. Store public key
| | | with user account
| | 8. Registration complete |
| |<--------------------------|
| 9. "Registration Complete" |
|<---------------------| |
| | |You initiate the Passkey registration process in the browser and you will be prompted by your device or password manager to create a Passkey. You device will create the cryptographic key pair, sign the challenge provided by the website, and then return the signed challenge along with your public key, which is stored against your account. The private key is kept securely on your device. Now that Passkey registration is complete, you can then use your Passkey for authentication.
User Browser / OS Website / Server
| | |
| 1. "Sign in with passkey" |
|--------------------->| |
| | 2. Request authentication |
| |-------------------------->|
| | |
| | 3. Send challenge |
| |<--------------------------|
| | |
| | 4. Biometrics / PIN |
| | 5. Sign with private key |
| | 6. Return signed challenge|
| |-------------------------->|
| | | 7. Verify signature
| | | using public key
| | 8. Authentication successful
| |<--------------------------|
| 9. "Signed in!" | |
|<---------------------| |When logging in to a website where you have registered a Passkey, you will usually have to initiate the process to sign in with your Passkey. In the background, your device will then start the authentication process and receive the challenge that needs to be signed with your private key. To do that, your device will ask for something like FaceID, TouchID, or similar on your device to authenticate you. Once you have authenticated to your device, it will sign the challenge with your private key and return it to the website. The website can then check it is definitely you by verifying that signature using your public key that it previously received, and then you're logged in! This is such a nice experience and has so little friction for the user, especially when you consider how strong this mechanism is.
How are they phishing-resistant?
When your device creates a Passkey, it doesn't just create and store the keys used, it also stores some important metadata too. The relevant part of that metadata that gives us phishing resistance is the Relying Part ID, or rpId. When you go to Report URI and register a Passkey on our website, the rpId will be saved with the Passkey on your device as report-uri.com and your device can then enforce that your new Passkey is only ever used on this domain or its subdomains. This means that if you end up on a phishing site that looks like Report URI, but isn't actually report-uri.com, the Passkey simply will not work. Take these examples that might make for convincing phishing pages:
https://report-url.com <-- nope
https://report-uri.secure-login.com <-- nope
https://report-uri.xyz <-- nopeThe only way that your device will now use the Passkey to log you in is if you're on a valid website where the Passkey is allowed to be used, effectively neutralising the threat of phishing!
How are they being used on Report URI?
There are two ways that you can use Passkeys on your website and they offer slightly different benefits.
- You can use Passkeys to replace passwords altogether, so they become your primary authentication mechanism.
- You can use Passkeys as a 2FA mechanism alongside your existing username/password authentication.
At Report URI we've opted for option #2 and now offer Passkeys as a 2FA option alongside our existing TOTP 2FA offering. Passkeys make for an incredibly strong second-factor and our primary goal was to achieve the phishing resistance that Passkeys offer. Looking at option #1 is also a valid approach and there are other benefits too, mainly being able to get rid of passwords from your database and protect against password based attacks. Given our extensive measures to protect user passwords, it was less of a concern for us to move to using Passkeys as our primary authentication mechanism and instead we chose to introduce them as a 2FA mechanism. If you're interested in our approach to securing user passwords, you can read my blog post that goes in to detail, but here is a summary:
- We use the Pwned Passwords API to prevent the use of passwords that have previously been leaked.
- We use zxcvbn to ensure the use of strong passwords when registering an account or changing password.
- We provide extensive support for password managers using attributes on HTML form elements.
- We store hashed passwords using bcrypt (work factor 10 + 128bit salt) so they are resistant to cracking.
Passkeys are now available on the Settings page in your account and we strongly recommend that you go and enable them!
In the coming week, I will also be publishing two more blog posts. One of them is the full details of the external engagement to have our Passkeys implementation audited. We engaged a penetration testing company to come in and do a full test of our implementation to make absolutely sure it was rock solid. The blog post will contain the full, unredacted report with details of all findings. The second blog post will be the announcement of our whitepaper on Passkeys and the new security considerations they bring if you're planning to use them on your site. Make sure you're subscribed for notifications so you know when they go live!