惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

博客园 - Franky
N
Netflix TechBlog - Medium
宝玉的分享
宝玉的分享
Google DeepMind News
Google DeepMind News
腾讯CDC
G
Google Developers Blog
Martin Fowler
Martin Fowler
Microsoft Security Blog
Microsoft Security Blog
Recent Announcements
Recent Announcements
爱范儿
爱范儿
Engineering at Meta
Engineering at Meta
Microsoft Azure Blog
Microsoft Azure Blog
A
About on SuperTechFans
aimingoo的专栏
aimingoo的专栏
有赞技术团队
有赞技术团队
Jina AI
Jina AI
人人都是产品经理
人人都是产品经理
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
M
MIT News - Artificial intelligence
罗磊的独立博客
博客园 - 三生石上(FineUI控件)
美团技术团队
WordPress大学
WordPress大学
阮一峰的网络日志
阮一峰的网络日志

Scott Helme

No Hacking Required: The Manchester Airports Group Data Breach The ultimate road trip combo: Starlink Mini + UniFi Travel Router Introducing dbsc.dev: Does Your Browser Support DBSC? Device Bound Session Credentials lands in Chrome on macOS Everything I Learned Shipping Device Bound Session Credentials Connection Allowlist: a network firewall, built into the browser Connection Allowlist: a network firewall, built into the browser Top 1 Million Analysis – June 2026: The State of Crypto Top 1 Million Analysis – June 2026: The State of Crypto Top 1 Million Analysis – June 2026: Ten Years of Web Security Top 1 Million Analysis – June 2026: Ten Years of Web Security A dead CDN, a wildcard, and an attack waiting to happen: the netdna-ssl.com takeover A dead CDN, a wildcard, and an attack waiting to happen: the netdna-ssl.com takeover Why No Passkeys? Naming the Top Sites That Still Don't Support Them Why No Passkeys? Naming the Top Sites That Still Don't Support Them The Instructure Canvas Breach (2026): How XSS in a Support Ticket Compromised 275 Million Students The Instructure Canvas Breach (2026): How XSS in a Support Ticket Compromised 275 Million Students Open-Sourcing dbsc-php: a Server Library for Device Bound Session Credentials in PHP Open-Sourcing dbsc-php: a Server Library for Device Bound Session Credentials in PHP DBSC Beta at Report URI DBSC Beta at Report URI Device Bound Session Credentials: Making Stolen Cookies Useless Device Bound Session Credentials: Making Stolen Cookies Useless Passkeys, Permissions Policy and Bug Hunting in 1Password's WebAuthn Wrapper Passkeys, Permissions Policy and Bug Hunting in 1Password's WebAuthn Wrapper Open-Sourcing passkeys-php: A Security-Focused WebAuthn Library for PHP Open-Sourcing passkeys-php: A Security-Focused WebAuthn Library for PHP XSS Is Deadly for Passkeys: The Hidden Risk of Attestation None XSS Is Deadly for Passkeys: The Hidden Risk of Attestation None Passkeys 101: An Introduction to Passkeys and How They Work
Launching Passkeys support on Report URI! 🗝️
Scott Helme · 2026-03-30 · via Scott Helme

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               <-- nope

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

  1. You can use Passkeys to replace passwords altogether, so they become your primary authentication mechanism.
  2. 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:

  1. We use the Pwned Passwords API to prevent the use of passwords that have previously been leaked.
  2. We use zxcvbn to ensure the use of strong passwords when registering an account or changing password.
  3. We provide extensive support for password managers using attributes on HTML form elements.
  4. 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!


Have you enjoyed this post or found it helpful?
☕️ Consider buying me a coffee to say thanks!
🔔 Subscribe for free notifications when I publish!
🤩 Become a member and support my content!

Tags: Passkeys, Report URI