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

推荐订阅源

宝玉的分享
宝玉的分享
T
Threat Research - Cisco Blogs
H
Hacker News: Front Page
N
News and Events Feed by Topic
Know Your Adversary
Know Your Adversary
Cisco Talos Blog
Cisco Talos Blog
SecWiki News
SecWiki News
C
Cisco Blogs
D
Darknet – Hacking Tools, Hacker News & Cyber Security
T
Tor Project blog
K
Kaspersky official blog
Forbes - Security
Forbes - Security
Webroot Blog
Webroot Blog
Schneier on Security
Schneier on Security
P
Privacy & Cybersecurity Law Blog
H
Heimdal Security Blog
Y
Y Combinator Blog
The GitHub Blog
The GitHub Blog
S
SegmentFault 最新的问题
V
Vulnerabilities – Threatpost
T
Tenable Blog
T
Tailwind CSS Blog
P
Privacy International News Feed
WordPress大学
WordPress大学
大猫的无限游戏
大猫的无限游戏
小众软件
小众软件
博客园 - Franky
Hacker News: Ask HN
Hacker News: Ask HN
Jina AI
Jina AI
C
Cybersecurity and Infrastructure Security Agency CISA
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
雷峰网
雷峰网
Vercel News
Vercel News
A
About on SuperTechFans
爱范儿
爱范儿
Simon Willison's Weblog
Simon Willison's Weblog
AWS News Blog
AWS News Blog
The Last Watchdog
The Last Watchdog
Engineering at Meta
Engineering at Meta
Spread Privacy
Spread Privacy
Security Archives - TechRepublic
Security Archives - TechRepublic
博客园 - 司徒正美
量子位
博客园 - 三生石上(FineUI控件)
J
Java Code Geeks
Hacker News - Newest:
Hacker News - Newest: "LLM"
Recorded Future
Recorded Future
H
Hackread – Cybersecurity News, Data Breaches, AI and More
Martin Fowler
Martin Fowler
Project Zero
Project Zero

Scott Helme

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: Ten Years of Web Security 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 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 DBSC Beta at Report URI Device Bound Session Credentials: Making Stolen Cookies Useless Passkeys, Permissions Policy and Bug Hunting in 1Password's WebAuthn Wrapper Open-Sourcing passkeys-php: A Security-Focused WebAuthn Library for PHP XSS Is Deadly for Passkeys: The Hidden Risk of Attestation None Passkeys 101: An Introduction to Passkeys and How They Work Anatomy of a WooCommerce Skimmer: A Technical Deep-Dive Under Attack: Responding to the Rise of Info-Stealer Threats Security considerations when using Passkeys on your website Fighting an active Magecart Campaign Amazing Refresh — A Malicious Chrome Extension Running Malware in the Browser Bringing in the experts; Having our Passkeys implementation Security Tested When “One in a Billion” Happens Every Day: Scaling Redis at Report URI Leverage our treasure trove of Threat Intelligence data XSS Ranked #1 Top Threat of 2025 by MITRE and CISA DNS-PERSIST-01; Handling Domain Control Validation in a short-lived certificate World
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