Introducing WebAuthn DevTools

2026-01-25T00:00:00Z

When implementing passkeys yourself or investigating how passkeys work on other websites, setting up a debugger to capture requests and responses or parsing binaries to read the contents is not easy. You can easily achieve this using a Chrome Extension called WebAuthn DevTools.

What is WebAuthn DevTools? #

WebAuthn DevTools is a Chrome Extension that streamlines WebAuthn debugging.

WebAuthn DevTools at the Chrome Web Store

You can use it immediately by launching Chrome DevTools on a page where WebAuthn is used and selecting the "WebAuthn" tab.

The left panel displays executed WebAuthn commands, and the right panel shows detailed requests and responses.

WebAuthn DevTools Screen

In particular, responses from navigator.credentials.get() and navigator.credentials.create() contain binaries, making it tedious to decode and read the contents, but WebAuthn DevTools displays parsed information on the spot. If the AAGUID is included, it also displays the name of the corresponding password manager.

WebAuthn DevTools Response Details

Also, some parameters display brief descriptions and links to learn more details.

Explanations displayed in WebAuthn DevTools

Summary #

The source code is available at GitHub. I'm also considering Safari and Firefox versions in the future. It is a handy tool for those interested in passkeys and WebAuthn for quick investigation and debugging. Please give it a try.

Key terminologies to get a grasp of passkeys

2025-12-14T00:00:00Z

At the FIDO Tokyo Seminar, I was told it's hard to track the high-level picture of how passkeys are evolving, and I thought it would be helpful to introduce key terminologies so you can get a grasp of the passkey world and look into more details when necessary. So here it is.

Standards #

FIDO #

FIDO (Fast IDentity Online) is a set of open standards for authentication. The FIDO Alliance develops these standards to reduce the world's reliance on passwords.

U2F #

U2F (Universal 2nd Factor) is an older FIDO standard for two-factor authentication. It uses a hardware security key as a second factor. FIDO2 is backward compatible with U2F.

Universal 2nd Factor (U2F) Overview | FIDO Alliance

UAF #

UAF (Universal Authentication Framework) is an older FIDO standard for passwordless authentication. It was designed for mobile devices and biometric authentication.

Universal Authentication Framework (UAF) Overview | FIDO Alliance

FIDO2 #

FIDO2 is the latest set of specifications from the FIDO Alliance. It enables users to leverage common devices to easily authenticate to online services in both mobile and desktop environments. FIDO2 consists of the W3C's Web Authentication (WebAuthn) specification and the FIDO Alliance's Client-to-Authenticator Protocol (CTAP).

FIDO2: Web Authentication (WebAuthn) | FIDO Alliance

WebAuthn #

WebAuthn (Web Authentication) is a browser API standard developed by the W3C. It allows web applications to create and use strong, attested, scoped, public-key-based credentials for the purpose of strongly authenticating users.

Web Authentication: An API for accessing Public Key Credentials

Basics #

Authenticator #

An authenticator is a device that stores and manages passkeys. It can be a hardware security key, a password manager (passkey provider), or a mobile device. In this article, a "password manager" represents authenticators (because it's the most frequently used authenticator).

Relying Party (RP) #

A relying party is a website or application that requests passkeys from the user. It is responsible for verifying the user's identity and storing the public keys.

RP ID #

RP ID (Relying Party Identifier) is the domain name of the website requesting the passkey. It defines the scope of the credential, ensuring that a passkey created for example.com cannot be used on evil.com. It must be a valid domain string and a suffix of the current origin.

PublicKeyCredentialCreationOptions - Web APIs | MDN

Discoverable Credentials #

Discoverable credentials (formerly known as "Resident Keys") are passkeys that are stored on the password manager along with the user's account information (like username and display name). They enable "username-less" authentication flows, where the user just clicks "Sign in" and selects their account from a list provided by the password manager.

Discoverable credentials deep dive | web.dev

User Verification #

User verification refers to the process of verifying that the person authenticating is the actual owner of the password manager, typically via a biometric check (fingerprint, face ID) or a PIN. A user verification happens locally, so information such as biometric data or PIN is not sent to the server.

userVerification deep dive | web.dev

Attestation #

Attestation is a cryptographic proof provided by the authenticator during credential creation. It allows the RP to verify the make and model of the authenticator (e.g., "This is a YubiKey 5 NFC"). This is primarily used in enterprise or high-security contexts to enforce policies (e.g., "only allow hardware keys"). In general, passkeys on password managers don't support attestations.

FIDO TechNotes: The Truth about Attestation | FIDO Alliance

AAGUID #

The AAGUID (Authenticator Attestation Globally Unique Identifier) is a 128-bit identifier indicating the type (model) of the authenticator. It allows RPs to identify the specific device being used (e.g., Google Password Manager, iCloud Keychain, Windows Hello, or a specific security key model) even without full attestation. It can be used to detect which password manager the passkey is created on to display the provider's icon, name, and other information by referencing MDS, but verification is not possible, since passkeys on password managers don't support attestations.

MDS #

The MDS (FIDO Metadata Service) is a centralized repository of information about FIDO authenticators. RPs can query the MDS using an AAGUID to retrieve details like the authenticator's certification status, icon, and supported features.

FIDO Metadata Service (MDS) Overview | FIDO Alliance

Implementation #

excludeCredentials #

excludeCredentials is a parameter that indicates a list of credential IDs that the server sends to the browser during the passkey creation process. It tells the password manager "if you already hold one of these credentials, don't create a new one." This prevents creating multiple passkeys for the same account on the same password manager.

Prevent creating a new passkey if one exists | web.dev

Conditional mediation #

Also known as "Conditional UI" or "Conditional Get", this feature allows passkeys to be offered in the browser's autofill suggestions on standard username input fields. It enables a seamless transition from passwords to passkeys by letting users sign in with a passkey directly from the form they are used to.

Signal API #

The Signal API allows RPs to communicate the state of a credential back to the password manager. For example, if a user deletes their account or a public key on the server, the RP can signal this so the passkey can be removed or updated on the supporting password manager as well.

Keep passkeys consistent with credentials on your server with the Signal API | Identity | Chrome for Developers

Related Origin Request allows a website to accept passkeys that were created for a different, but related, origin. This is useful for multi-domain deployments (e.g., example.com and shop.example) or country-specific deployments (e.g., example.com and example.co.jp).

getClientCapabilities #

getClientCapabilities allows RPs to query the browser to see which WebAuthn features are supported on the current device. It helps in making decisions about the UX, such as checking if conditional mediation is supported before setting up the form.

Simpler WebAuthn feature detection | web.dev

Client Hints #

Client Hints allows RPs to provide a hint to the browser about which type of authenticator the user is expected to use (e.g., security-key or client-device). This helps the browser to show a more relevant UI to the user, improving the user experience especially in enterprise environments where specific authenticators are required. Note that this is only a hint and does not enforce security policies.

Client Hints | passkeys.dev

Passkey endpoint #

Passkey endpoint refers to a mechanism (often involving a .well-known file) that allows RPs to signal to password managers (like Google Password Manager) that they support passkeys. This enables the password manager to proactively suggest upgrading an existing password account to a passkey.

Conditional creation #

Also known as "Automatic passkey upgrade" or "Automatic passkey creation". An emerging feature that allows RPs to piggyback the passkey creation request onto a password sign-in or other user action. If the user successfully signs in with a password, the browser can automatically (or with minimal friction) create a passkey for future use.

Help users adopt passkeys more seamlessly | Identity | Chrome for Developers

Immediate mediation #

A proposed feature that immediately returns an error when a credential request is canceled or failed. This allows the RP to improve the user experience by not showing a QR code or other authentication methods and control the fallback authentication method.

Origin trial: WebAuthn immediate mediation for frictionless sign-in | Blog | Chrome for Developers

Finally #

If you think this article is missing any important keywords, please let me know via @agektmr.

Renewed the blog system

2025-11-30T00:00:00Z

I have revamped this blog. The appearance is almost the same, but I have introduced an English version with multilingual support (i18n) and changed the infrastructure.

Background of the renewal #

Until today, this blog has been serving technical information primarily in Japanese, but I was wanting to provide it in English too, for some time. There were some ideas in my mind on how to do it, but just couldn't find the time. With the recent rise of AI coding agents, I decided to jump on the bandwagon. Also, I haven't had much opportunity to write code for work lately, but I feel urged to understand, even just a little, what it feels like to be an every-day coder, so I decided to give it a try. I often use Gemini at work, so I decided to use Claude Code at this time, which many people around me use.

Main changes #

1. Multilingual support (i18n) and URL structure changes #

The biggest change in this renewal is multilingual support. Until now, articles were mainly in Japanese, but English versions will also be available.

Japanese articles have been placed directly under the root directory, but they are now separated into directories for each language as shown below.

Japanese: /ja/
English: /en/

This makes it easier to switch between languages. We've also added a new language switch, so you can switch languages if an article exists.

2. Automatic translation using Google Cloud Translation API #

For translation, I've (asked to) add an automatic translation system using the Google Cloud Translation API, so I can translate using a script and I can make manual corrections as needed (past articles were translated mechanically in bulk, so I plan to correct any strange parts as they are found). This allows me to create a workflow that allows me to write articles in Japanese and then publish them in English with relatively little effort.

3. Infrastructure Changes: Migrating to Cloud Run #

To support multiple languages, I switched my blog hosting from Jamstack Netlify to dynamic delivery by Google Cloud Run. Since the only server logic I needed was language detection, Firebase Hosting + Cloud Functions would have been fine, but I just wanted to try Cloud Run. I also wanted to get reacquainted with Docker, something I hate to learn and then forget (although I haven't actually reacquainted with it yet, since Claude Code did most of the heavy lifting for me).

4. Introducing organicity #

As an added bonus, I've introduced "organicity" as an indicator of how much of a blog post is written manually. For example, "organicity: 50%" means that 50% is written manually, meaning the remaining half relies on AI. I think this will become the norm in the future. However, this number is subjective and self-reported, so please take it as a grain of salt.

Future outlook #

With this renewal, I have established the foundation for disseminating information in multiple languages. From now on, I would like to actively disseminate technical information not only in Japanese but also in English. If you find anything strange, please let me know.

I hope you continue to enjoy my new blog.

I wrote a book called "All About Passkeys."

2025-01-13T00:00:00Z

I have written a book called "All About Passkeys" (https://gihyo.jp/book/2025/978-4-297-14653-5). I would like to give you a brief introduction to the contents of this book, which will be released on January 28th.

パスキーのすべて

I wrote "All About Passkeys" together with Mr. Koiwai, a director of the OpenID Foundation in the United States and leader of the OpenID Foundation Japan's KYC Working Group, and Kura, a director and evangelist at OpenID Foundation Japan. Mr. Koiwai also helped me with last year's Passkey Hackathon, and we've often spoken at the same events. He's been helping me out with various things recently, not just FIDO-related. Mr. Kura and I have been good friends in the ID community for over 10 years. We are both friendly and enjoyable colleagues. While we roughly divided the work, we all took responsibility for the overall writing. Toward the end, we all retreated to the Gijutsu Hyoronsha conference room several times to write and review the book, which made the process itself a lot of fun. I'd like to thank Mr. Kikuchi, the editor, for his help, even on his day off.

As the title suggests, this book covers not only the technical aspects of Passkey, but also its origins, ecosystem, surrounding circumstances, and more, incorporating all of our knowledge. For a rough overview, it's best to take a look at the Table of Contents, but I'd like to share some of my personal highlights.

Contains basic information that PMs and designers need to know.
Contains the essentials that engineers need to know to implement passkeys.
Includes a wealth of information for advanced users.

A collection of basic information that PMs and designers need to know #

はじめに

This book is intended to be read by a wide range of members of teams working on passkeys, and contains a lot of information that will be useful for PMs and designers as well, such as what passkeys are, the benefits of using them, user experiences with passkeys, case studies, common misconceptions and their solutions, and pitfalls. In particular, the information on passkey support on each platform across operating systems, browsers, and password managers will be extremely useful when designing services.

サポート環境

It also introduces the features and usage of widely used authentication methods such as passwords, two-factor authentication, and ID linking, and touches on what authentication methods other than passkeys are available, how they should be handled, and what to do if your passkey becomes unusable. Passkeys are not the only thing you need to consider when designing authentication functions.

Contains the essentials that engineers need to know to implement passkeys #

This book provides various sample code, covering not only browser-side implementations and WebAuthn API references that align with the basic user experience, but also server-side implementation methods. It also introduces implementations for native Android and iOS apps, and provides sample code for iOS apps, for which there is little information available in Japanese.

パスキーのUXを実装する

Packed with information for advanced users #

To encourage wider adoption of passkeys, various measures are required. To meet these needs, the book also contains a wealth of information for advanced users. It covers topics such as how to find out where passkeys are stored, how to use the same passkey for multiple domains, what attestation is, how to implement passkeys using security keys in the enterprise, details of credential payloads, and various extensions.

Although the technology industry has a short shelf life, this book covers the latest specifications for WebAuthn Level 3, which is expected to become available in the near future, making it a book you can refer to with confidence for the next two years.

lastly #

While passwords are easy to use, they have many pitfalls and require far too many precautions for anyone to use them safely, resulting in a constant stream of account hijacking. Passkeys, when implemented correctly, are easy for anyone to use and are an authentication feature that ensures security not possible with previous technology. While there is still room for growth, the time is ripe. Now is the time to start considering implementing passkeys.

I usually share information about passkeys through events and social media as part of my job, and occasionally through this blog and magazines as a hobby. The reason I decided to try the book format this time was because I once again realized the comfort of having a medium that allows me to have comprehensive information at my fingertips. If you are learning about passkeys, I would encourage you to have this book at hand.

Tips for using your passkey

2024-12-26T00:00:00Z

Recently, I've seen a lot of people complaining about passkeys being difficult to use. I've also seen several posts from people who have trouble logging in to services they want to use because they can't find the passkeys they thought they had created.

So in this blog post, I would like to consider why this happens, how to avoid such situations, what measures users can take, and what service providers can do to reduce the number of users who feel this way.

Of course, a basic premise is that features that require users to think hard to use are undesirable, as they will cause inconvenience rather than promote widespread adoption. However, while Passkey is maturing as a product from each company, it is still in the early stages of development as a total ecosystem, and it cannot be denied that there are some aspects that are difficult to use. Therefore, I am writing this article in the hope that by sharing some ingenuity, I can help ease the burden on everyone until the world becomes more user-friendly.

Passkey Basics #

First, I wrote about what Passkey is and what kind of world it aims to create in What is Passkey and its Challenges?. It's been two years since I wrote that article, but the fundamentals haven't changed much. However, during that time, operating systems, passkey providers (password managers), browsers, and services (Relying Parties or RPs) have all gradually evolved.

What makes passkeys difficult to use? #

From what I've observed, the main reasons people find passkeys difficult to use are as follows:

I created a passkey, but I can't find it.
I don't know what to do when my passkey doesn't work.

There are probably many other minor issues, but if these are resolved, the remaining problems will likely be minor.

Passkey not found #

"The service asked me to create a passkey, so I did, but it disappeared when I moved to another environment. I was told that the passkey would be synchronized, but I can't find it now."

This situation may occur for the following reasons:

The passkey provider where you saved your passkey cannot be accessed from the new environment.
The passkey provider is available, but you cannot access the account where you saved your passkey.
The passkey from the passkey provider is not synchronized in the first place.
The biometric authentication feature you thought was a passkey is not actually a passkey.
You cannot log in because the service does not offer any authentication methods other than passkeys.

1. The passkey provider that saved the passkey cannot be accessed from the new environment. #

A passkey provider is a place where you can save and synchronize the passkeys you create, and in most cases, a "password manager" also serves this role. The default passkey provider where your passkeys are saved is determined by your environment. In most cases, the passkeys you create will be saved in the system's default passkey provider.

If you can't find your passkey, it may be due to an incompatibility between your devices. For example, a passkey created in Edge for Windows cannot be accessed from Edge for Android. This is because the passkey created in Edge for Windows is stored in Windows Hello, while Edge for Android only works with Google Password Manager.

The passkey provider support status for each environment is described below.

2. The passkey provider is available, but you can't access the account where the passkey is stored #

Another possibility is that even if you use the same passkey provider, you can't find your passkey because you saved it in a different account. For example, if you create a passkey in Chrome, by default it's saved in the Google Password Manager linked to the Google Account you're logged in to Chrome with. If you want to access the same passkey in a different environment, you'll need to access it in Chrome logged in with the same Google Account. If you use multiple Google accounts, you might want to check whether the account you're using to access the passkey is the same one you saved previously.

Android also has a feature called Work Profile that completely separates apps and data for personal and work accounts within the same OS. I've personally experienced panicked situations where I couldn't find my passkey because of this feature. If you can't access your passkey, please check the following.

3. The passkey provider's passkey is not synchronized in the first place #

In fact, there are cases where passkeys are not synchronized. As of the end of 2024, passkeys will not be synchronized in the following three cases:

Created a passkey for Windows Hello #

One issue many people are likely to encounter is creating a passkey in Windows Hello. Previously, passkeys created in any browser were not synced, and even now, with the exception of Chrome on TPM-enabled Windows devices, passkeys created in any browser are not synced once they are saved in Windows Hello.

You created a passkey in iCloud Keychain on macOS, iOS, or iPadOS and tried to access the passkey from a non-Apple device #

When you create a passkey on macOS, iOS, or iPadOS, it's often stored in iCloud Keychain or the Passwords app. Passkeys stored in iCloud Keychain won't sync with Windows or Android as of the end of 2024, so they won't be available. There are Windows apps and browser extensions, so hopefully they'll support passkeys.

I created a passkey for a service that I don't want to sync #

Android still has a FIDO2 feature that predates passkeys, which allows you to create passkeys that are not synchronized. Since passkeys should be synchronized, it may be more appropriate to simply call them "FIDO2 credentials." Of course, this feature is no longer recommended, but it is still used intentionally by some services because it offers the strongest security.

4. The biometric authentication feature you thought was a passkey is actually not a passkey #

When you encounter biometric authentication on your smartphone, you might immediately assume it's a passkey, but not all of them are passkeys. Android apps have a feature called BiometricManager, and iOS apps have a feature called Local Authentication Framework, so this may be a misunderstanding. These features can usually only be set up after logging in to a banking app or similar app using a different method.

5. I can't log in because the service doesn't offer any authentication method other than a passkey #

Whether you use a passkey or not, as long as you can log in, that should be fine for the user. However, there are some services that, once you create a passkey, you cannot use any other authentication method. You might think that's outrageous, but let's stop and think about it for a moment.

There are two points to consider when considering whether authentication methods other than passkeys should remain:

If you leave authentication features weaker than a passkey, they will be targeted by attackers.
Removing all authentication features weaker than a passkey will make your device safe, but removing the passkey will put you in trouble.

Approach 1: Preserve authentication mechanisms weaker than a passkey

Adding a passkey as a new authentication option to your existing authentication methods doesn't fundamentally improve the security of the system as a whole, but the passkey experience has the advantage of being quicker and easier to log in with fewer steps than other secure authentication methods (such as two-factor authentication).

Ideally, weak authentication functions should be strengthened or eventually eliminated while waiting for the passkey ecosystem to become more robust in the future. If authentication can be easily achieved with a passkey, even if other authentication methods require a little more effort, it is far better than being stuck with the loss of the passkey. With a passkey, existing authentication methods are positioned as merely useful in emergencies, and even if the experience is slightly worse, such as by increasing the number of authentication steps, it should be acceptable. It would be wise for many services to adopt this approach.

Approach 2: Eliminate authentication mechanisms weaker than a passkey

But what if your company's users were currently being subjected to brutal phishing scams, causing daily losses? It wouldn't be surprising if there were services that would completely switch to Passkey, which would reduce phishing scams, even if it meant users had some access issues and could recover by verifying their identity through support. In our previous article, we listed services that support Passkey, but aren't you surprised that so many of them are major companies? Usually, it's small, ambitious companies that jump on new technologies; larger companies tend to be slow to act. Despite this, I imagine the major companies all supported Passkey because they wanted to quickly implement a countermeasure against phishing scams.

Tips for users to master passkeys #

As we have seen, there are still pitfalls in Passkey as an ecosystem. Here are some suggestions on how general users can use Passkey in a positive way.

Display a QR code and attempt to log in with a passkey from another device (cross-device authentication)
Be aware of which passkey provider you have saved your passkeys to
Create passkeys for multiple passkey providers

Tip 1: Display the QR code and try logging in with the passkey on another device (cross-device authentication)

If you can't find your passkey, you may be able to log in using a passkey saved on another device. If the passkey dialog doesn't show "More options," tap it to display a QR code, then scan it with the device that has your passkey to see if you can log in.

Tip 2: Be aware of which passkey provider you store your passkeys with #

When creating a passkey, it's easier to understand the situation if you consider which passkey provider you're saving it in. Below is a summary of which passkey providers can be used in which environments.

There are three main passkey providers:

Microsoft's Windows Hello
Apple's iCloud Keychain (or "Passwords" app)
Google's Google Password Manager

Browsers run on the operating systems of these platforms, but the passkey providers that can actually be used vary depending on the combination. Below we've summarized which passkey provider your passkey is stored in for each operating system and major browser. We recommend that you find the combination that best suits the apps and browsers you access most frequently.

For example: If you only use Apple devices, storing your passkey in iCloud Keychain may be sufficient, while Windows and iPhone users may want to use iCloud Keychain in conjunction with Google Password Manager.

*I haven't checked all Chromium-based browsers, but I think most of them are probably the same as Edge. For the latest information, please refer to passkeys.dev.

Windows #

	Chrome	Edge	Firefox
Google Password Manager	✅️ (Requires TPM)	❌️	❌️
Windows Hello	✅️	✅️	✅️
iCloud Keychain	-	-	-

macOS #

	Chrome	Edge	Firefox	Safari
Google Password Manager	✅️	❌️	❌️	❌️
Windows Hello	-	-	-	-
iCloud Keychain	✅️	✅️	✅️	✅️

iOS/iPadOS #

	Chrome	Edge	Firefox	Safari
Google Password Manager	△¹	❌️	❌️	❌️
Windows Hello	-	-	-	-
iCloud Keychain	✅️	✅️	✅️	✅️

¹ Coming soon

Android #

	Chrome	Edge	Firefox
Google Password Manager	✅️	✅️	✅️
Windows Hello	-	-	-
iCloud Keychain	-	-	-

Linux #

	Chrome	Edge	Firefox
Google Password Manager	✅️	❌️	❌️
Windows Hello	-	-	-
iCloud Keychain	-	-	-

ChromeOS #

	Chrome
Google Password Manager	✅️
Windows Hello	-
iCloud Keychain	-

Third-Party Passkey Providers #

Other third-party passkey providers (non-default password managers) that support passkey include:

1Password
Dashlane
BitWarden
NordPass
RoboForm
Keeper

The advantage of many third-party passkey providers is that they are platform-agnostic and can be used anywhere.

Tip 3: Create passkeys for multiple passkey providers #

Depending on the service, passkeys are designed to allow multiple passkeys to be created for each account. Creating multiple passkeys across multiple passkey providers, such as Google Password Manager and iCloud Keychain, can significantly reduce the trouble of losing your passkey. Even if you accidentally delete your passkey, you can recover it using another passkey.

Additionally, if you're using Android 14 or later, or iOS/iPadOS 16 or later, you can specify multiple third-party passkey providers at the OS level.

Android: System Settings > Passwords & Accounts
iOS/iPadOS: Settings > General > Autofill & Passwords

Even on desktop, most third-party passkey providers offer browser extensions that you can use, so this is a good opportunity to start using a third-party passkey provider.

Tip 4: Wait until a passkey becomes more convenient

Since things have been going in a rather negative direction, let me offer some positive news. Here are some upcoming changes (probably sometime in 2025) that will improve the usability of passkeys:

Passkeys created in Chrome are currently stored in the Google Password Manager and can be synced across Android, Windows, macOS, Linux, and ChromeOS, and will soon be synced to iOS/iPadOS as well. This means that as long as you use Chrome, you'll be able to use the same passkey across all environments via Google Password Manager.
In October 2024, Microsoft announced that it plans to soon sync passkeys across Windows devices. It's likely that some movement will occur sometime in 2025.
In October, the FIDO Alliance announced specifications called CXP (Credential Exchange Protocol) and CXF (Credential Exchange Format) to enable the secure import and export of passkeys and passwords. This will enable passkeys to be copied and moved between passkey providers in the future.

Hopefully, passkeys will be even more convenient to use in 2025!

Services that can make passkeys more convenient to use #

Finally, we will consider what points service providers should pay attention to when implementing passkeys so that users can use them with confidence.

Let users know which passkeys cannot be synced and which passkey providers they use #

The Passkey Design Guidelines recommend creating a Passkey Management screen. You can help users understand by clearly indicating which Passkey provider stores the passkey and whether or not it is synchronized.

Adjust passkey promotion frequency #

It seems that some users don't like the pressure to use a passkey. I think passkeys are a good thing, but pushing them too much may have the opposite effect.

Guide to authentication methods other than passkey #

Unless there are extraordinary circumstances, provide a backup authentication method in case a passkey cannot be used. ID linking, two-step authentication, and in some cases passwordless methods such as magic links are also acceptable. Of course, you should take all possible security measures for each method. However, since password-only logins are vulnerable to attacks, you should move to ID linking, passwordless authentication, two-factor authentication, etc. as soon as possible.

Change behavior for each environment #

For example, even for Windows, passkeys created in browsers other than Chrome will not be synchronized as of the end of 2024. By identifying the user agent string and explicitly stating that passkeys created in such browsers will not be synchronized, it may be possible to control user expectations to some extent.

Follow the guidelines #

The FIDO Alliance recently launched a website called Passkey Central. It's not aimed at developers, but it contains many resources that product managers and designers can refer to. I highly recommend checking it out.

summary #

We've put together a comprehensive guide to using passkeys. Some of you may feel like you can't master something so complicated! But as a user, that's not a bad feeling. The goal of passkeys is to provide a secure authentication system that anyone can use without having to think about these things at all. It may take a little more time until that happens.

Finally, here are some tips that we've covered in this article:

Tips for users to use passkeys effectively:

Utilize cross-device authentication
Be aware of which passkey providers you store your passkeys in
Create passkeys for multiple passkey providers
Wait until passkeys become more convenient

Tips for service providers to successfully implement passkeys:

Adjust the frequency of passkey promotion
Indicate the passkey provider and synchronization status of registered passkeys
Keep authentication methods other than passkeys available if possible
Change passkey creation behavior for each environment
Follow guidelines

Have a great new year.

The basics of passkeys and clearing up misconceptions surrounding them

2023-12-18T00:00:00Z

2023 has undoubtedly become the "first year of passkeys." With so many services supporting passkeys, 2024 is likely to be the year when passkeys finally become widespread.

In this article, we will review the basics of passkeys and explain some common misconceptions about passkeys.

In 2023, many websites now support passkeys. For example:

-Adobe

Amazon -Apple
eBay
GitHub
Google
KDDI
Mercari
Mixi
MoneyForward
Nintendo
NTT Docomo -PayPal
Shopify
Toyota -Uber -Yahoo! JAPAN

Of course, this list is not exhaustive, but even just these should cover a large portion of the world's population, making it a huge leap forward. If you haven't tried Passkey yet, now is your chance to give it a try.

That said, at this stage, the number of actual users is not the same as the covered population, and even from a developer's perspective, there is still room for improvement in the user experience and implementation, and it feels like it will take at least two or three years for it to mature. First of all, I am writing this article in the hope that as many people as possible will gain more accurate knowledge of passkeys.

I would be delighted if Passkey could help create a world where logging in is no longer a barrier to using the latest technology, and where even someone like your mother can easily and securely use the functions of websites and apps without having to consult with an expert.

Passkey Basics #

First, let's review the basics of passkeys. I've created a short video summarizing passkeys, so please take a look. It's in English, but you can translate it and get Japanese subtitles.

Simply put, a passkey is a mechanism that allows device owners to log in to websites and apps using a key stored on the device.

You can create multiple passkeys for each site and app.
When creating a passkey or logging in, local device authentication such as unlocking is required.
Passkeys are stored in a password manager and can be synchronized across devices.
By forcing users to use a password manager, users are less likely to fall victim to phishing scams.
Since only public keys are stored on the RP (Relying Party) server, the chances of account login information being stolen are extremely low.

If you'd like to go into more detail, I've covered this topic twice on this blog, so please take a look.

Clearing up misconceptions about passkeys #

Now that we've covered the basics of passkeys, we'll clear up some common misconceptions about passkeys.

December 19, 2023: Misconceptions 10 to 13 have been added.
December 21, 2023: The content of Misconceptions 10 and 11 has been revised for clarity.

Myth 1: Using a password manager is enough to keep me safe, so there's no point in using a passkey #

This is true in a sense. The point of using a passkey is that it forces you to use a password manager.

It's true that even if you continue to use passwords, if you use a password manager, it will automatically generate complex passwords for you, you don't have to remember them, and it will enter them into the appropriate domain, so you're less likely to fall victim to phishing scams.If you use it properly, you may not need a passkey.

The problem is how to protect people who do not have the literacy to use password managers or who do not know how to use them. Password managers have been available for many years, but the number of password leaks and account hijackings has not decreased because the existence of such managers alone does not solve the problem.

While websites and apps don't want to incur support costs for users who forget their passwords or have their two-factor authentication stolen through phishing, they can't force users to use a password manager. That's what Passkey does.

KDDI reports that the introduction of passkeys has reduced authentication inquiries by 30%.

Myth 2: If I lose my device, will my passkey become useless? #

Your synced passkey can be recovered even if you lose your device.

In many cases, your passkey can be backed up to the password manager's server, so if you lose your device, you won't immediately be unable to log in again. If you can log in to the same password manager account on another (or new) device, you can restore your passkey. For example, if you lose your Android device, you can recover your saved passkey from another device as long as you can log in to your Google Account.

To explain how synchronization works in more detail, for example, if you use Google Password Manager on Android, the saved passkey is encrypted using the device's PIN or pattern and backed up to Google's servers. When transferring to a new device, you first log in to your Google account, then enter the PIN or pattern from your old device to sync and decrypt the passkey and use it to log in. It's similar on Apple devices.

If you lose your device and think it has fallen into the wrong hands, you may find it more reassuring to remotely wipe the entire device.

Misconception 3: If I use a passkey, can someone steal my account? #

Everyone has been thinking about why passkeys are vulnerable and coming up with various ideas. Of course, there is discussion about the problems that need to be solved and the problems that can be solved, but when people ask questions like, "What if your device is stolen?" or "What if someone cuts off your finger and authenticates you?", the answer is often, "Passkeys don't prevent physical crimes." It's a bit harsh to say that passkeys shouldn't be used for these reasons.

Think about it.

Which is better: continuing to use a password that is subject to endless, unknown remote attacks such as server leaks, phishing attacks, and list attacks, or a passkey that can only be attacked if the device is in your possession?

Which is better: two-factor authentication, which requires a one-time password received via SMS or email, resulting in a worse login experience in exchange for security and leaving users vulnerable to remote phishing attempts, or a passkey that can only be used to log in to legitimate domains by unlocking the device?

Although it's not perfect, the number of users protected by a passkey seems to be overwhelmingly large.

Myth 4: I don't want to use a passkey because it would make me completely dependent on Big Tech for my valuable authentication. #

Passkeys can be stored, synced, and used in a third-party password manager other than the default password manager provided by your OS vendor.

By default, passkeys are stored in iCloud Keychain on Apple devices and Google Password Manager on Android devices. Fortunately, both Apple and Google offer a way for users to store and use passkeys in a third-party password manager, depending on the OS version. 1Password and Dashlane already support passkeys, so you can choose to use them if you need them.

(Microsoft doesn't yet support passkey syncing, so it's unclear whether it will enable third-party password managers.)

By the way, there is talk that if your Google or Apple account is banned, your passkey will also become unusable, but in many cases, the passkey is synced locally, so I think you can continue to log in using it (please check).

Myth 5: If my password manager account is compromised, all my passkeys are compromised too #

This is not wrong, but it's worth understanding a few more details.

It's a legitimate concern that if a password manager account that syncs passkeys is compromised, all of the stored passkeys could be stolen, making it dangerous.

Google accounts can be compromised, and so can iCloud accounts. Third-party password managers like 1Password and Dashlane are also notoriously vulnerable.

As mentioned above, Google Password Manager (and probably iCloud Keychain as well) encrypts and backs up your passkey using the device's PIN or pattern. Other password managers likely have their own similar mechanisms. Therefore, even if your account is stolen, it doesn't necessarily mean that your passkey will be leaked at the same time. It might be a good idea to check how the password manager you're using is designed just to be safe.

You might think that if you don't sync your passkey, the problem is solved. That's true, but that also has its own problems. For example, if you switch to a new device, you'll need to create a new passkey for each site where you created a passkey on that device. However, you won't be able to link it to your account unless you authenticate once before that. So how can you authenticate without using a passkey?

What you need to be careful about is that if you cannot log in using an authentication method that is equivalent to or more powerful than a passkey, that will create a hole.

Also, if you create 100 passkeys, you will have to authenticate using a method other than the passkey and register a new passkey 100 times. Anyone who has ever broken a security key will know how painful this is.

In that sense, I think that synchronizing passkeys is an excellent solution that can maintain a certain level of security without degrading the user experience.

In addition, a new specification called Supplemental Public Key has been created that combines the best of both passkey synchronization and device binding. This is a general-purpose alternative to the Device Public Key introduced in a previous article, but as this feature is implemented further in the future, it will be possible to create passkeys with even higher security.

Misconception 6: Is a passkey more secure than a password because it uses biometric information? #

Many people associate passkeys with biometric authentication based on their appearance, and this is one of the misconceptions that arises from this.

The idea that passkeys are more secure and have higher entropy than passwords, which are typically only a few dozen characters, is that they use complex biometric information, but this is incorrect. The role of biometric authentication in passkey authentication is to trigger the issuance of a public key cryptographic signature.

The passkey is based on public key cryptography, and is created by storing the public key on the RP (Relying Party) server and the private key in a password manager. The passkey here refers to this private key and its metadata.

When using a U2F-compatible security key for two-factor authentication, touching the metal chip on the surface is the trigger. This is because the requirement for physical contact prevents remote software spoofing. The same is true for two-factor authentication on some smartphones, where you must press the volume button instead of tapping the screen. Because the button is connected to the security chip inside the device, it can be proven that it was physically pressed.

While U2F relies on proving someone's presence as the second factor, FIDO2 (passkey) uses device biometrics to at least verify that the person is the device owner. This is why biometric authentication can be used without biometric authentication, as long as you know a method to unlock the device, such as a PIN, passcode, or pattern. This is called user verification, and as mentioned in a recent blog post, it can be combined with proof of device ownership to form two-factor authentication in one step.

By the way, on Android and iPhone, biometric information is stored in secure hardware such as the Secure Enclave, so the data cannot be extracted or sent over the network.

Updated 12/26/2024: Over time, opinions have shifted regarding whether a passkey alone constitutes two-factor authentication. With FIDO2 authentication (authentication using WebAuthn, which predates passkeys), credentials were stored on a secure chip on the device, and local authentication reliably used the device's built-in features, making it undoubtedly two-factor authentication. However, with passkeys, credentials are stored in a password manager of the user's choosing, and local authentication is also specified by the password manager, making it unclear how reliable the local authentication certificate is. Some password managers, like 1Password, return the UV flag with true even when skipping local authentication.

Taking all of this into consideration, I have come to the conclusion that passkeys are not two-factor authentication. However, I don't think that just because they aren't two-factor authentication makes them weak. Rather, I understand that thanks to passkeys, the era of measuring strength based on whether or not it is two-factor authentication is over. For more details on this, I recommend reading Koiwai's article and Yuriy Ackermann's article.

Myth 7: Your passkey syncs across all your devices #

Passkey aims to create a world where it can be synchronized across various devices. However, due to technical reasons, not all Passkeys are yet capable of synchronization, and the original expression was "synchronize for each ecosystem (platform)." The actual synchronization conditions are as follows:

Safari #

Apple's ecosystem is such that the Safari browser and almost all compatible apps run only on Apple devices, so whether you're using macOS, iOS, or iPadOS, the passkey you create is stored and synced to iCloud Keychain by default and can be used on other Apple devices, making it very simple. The same goes for iOS apps.

Chrome #

Chrome works across multiple platforms, including macOS, iOS, iPadOS, Windows, Android, and Linux.

Passkeys created on Apple devices, including macOS, are primarily stored in iCloud Keychain, so they sync in much the same way as Safari.

Passkeys saved on Android are stored in Google Password Manager by default and sync across Android devices, with support for Chrome OS coming soon.

For Windows, we rely on a Microsoft mechanism called Windows Hello, but unfortunately the Windows Hello passkey is not yet synced.

As you can see, Chrome's sync support is currently dependent on the OS it's running on. This is documented by Google.

Firefox #

Firefox, which uses Gecko, another of the three major browser engines, doesn't officially support passkeys, so it's not yet clear how passkeys will be synced, but it looks like it could happen by early 2024.

Third-Party Password Managers #

By the way, third-party password managers often have cross-platform compatibility, so synchronization is very flexible. In most cases, you can expect synchronization across all environments.

Passkey authentication using QR code #

Even if your passkey is not synchronized and cannot be used, you can still log in using the passkey from another device by scanning the QR code.

If you create a new passkey after this, you will be able to use it to log in in that environment from the next time.

Myth 8: Is a passkey a synced FIDO credential? #

There is some confusion about the definition of a passkey, but I personally call any discoverable credential a passkey.

The FIDO Alliance initially defined "passkey" as a FIDO credential that synchronizes, or in other words, a discoverable FIDO credential. (A discoverable credential is a saved passkey for a username that also triggers synchronization on Android.) However, this was later rewritten as "all FIDO credentials." The Alliance also began to distinguish between a synchronized passkey and a device-bound passkey.

Misconception 9: Will implementing a passkey completely eliminate the need for passwords? #

Because passkeys allow authentication without a password and are synchronized, ideally site operators would eliminate passwords as soon as possible after implementing passkeys, as leaving them open to attacks remains a possibility. However, there are many other things to consider before eliminating passwords.

For example, there is no guarantee that a user will not delete their only passkey, and if that happens, you should carefully consider how to recover their account.

There are several ways to recover your account without using a password, such as sending a one-time password via SMS, sending a magic link via email, or having the user contact support by phone. This process is called account recovery.

As you may have already noticed, no matter how much security a passkey improves, if account recovery is easily targeted by attackers, the point of introducing a passkey is halved.

At the same time as implementing a passkey, please also consider improving your authentication functions as a whole.

Misconception 10: You can only create one passkey #

How the passkey you create connects to websites and apps is one of the most confusing topics.

It is a common misconception that there is only one passkey and that once registered, the same passkey will be used across all websites and applications.

A passkey (public key pair) is created for each website and app account.

It is a misconception that, like passwords, you can only create one passkey per website or app account.

You can create multiple passkeys for each account. So, by creating multiple passkeys, such as one for Android, one for Windows, one for iCloud Keychain, and one for 1Password, you can create an environment where you can log in quickly from anywhere, and if you accidentally lose access to one of them, you can use the others as backups.

However, most password managers only allow you to save one password for the same account, website, or app combination, so there's no benefit to having multiple passwords in the same password manager, and you'll usually get an error if you try.

Myth 11: If I lose access to the Google or iCloud account I use for syncing, my passkey will become useless. #

As mentioned in Misconception 4, in many cases, passkeys are synced locally, so even if you lose access to your password manager account, you should be able to log in as long as the passkey remains locally. This is especially true for Google accounts and iCloud accounts, which generally remain locally (although I've never actually had an account banned, so please check).

If you find yourself in this situation and your passkey remains only locally, we recommend creating a new one using another password manager.

Misconception 12: Passkeys can only be used on smartphones #

It seems that more people than you might think think that a passkey requires a smartphone, but this is a misunderstanding.

Passkey is also supported on desktops and laptops. Many devices don't support biometric authentication, but in those cases, you can use local authentication with a PIN (Windows) or a system password (macOS) to authenticate using the passkey.

I mentioned that if you only have a passkey on your smartphone, you can authenticate using a QR code, but if you then create a new passkey in your desktop environment, you will be able to log in using only your computer from then on, without having to scan the QR code every time.

Misconception 13: Creating a passkey prevents other authentication methods from working #

No service I've seen has ever removed all other authentication methods in favor of making a passkey available.

Therefore, there is no need to worry about creating a passkey and being locked out. In most cases, you should still be able to use the same login method as before. Why not give it a try?

summary #

I hope this article clarifies some of your questions about passkeys. If you have any questions that aren't answered here, please let me know at @agektmr and I might add them to this article.

Finally, here are some resources for those who want to keep track of Passkey information:

Google's Official Passkey Developer Documentation: Contains an overview of passkeys, UX guides, case studies, and other passkey-related information for both Android app and web developers. (The Japanese text is machine-translated, but there's a bug where the left navigation isn't up to date when translated into Japanese. Please temporarily switch to English to get the full picture.)
Google's Official Passkey Developer Documentation: Contains passkey-related information for web developers.
Android Developer Documentation: Contains passkey-related information for Android developers. Going forward, all Android app authentication will be migrated to a library called Credential Manager, so this information is part of that documentation.
Passkey Developer Newsletter: Receive email notifications of updates to Google-related passkey implementations.

FIDO Alliance Homepage
FIDO Alliance Official UX Guide (English)
Community-Driven Passkey Documentation (English)

Photo by Tierra Mallorca on Unsplash

What is a passkey and its challenges?

2022-12-13T00:00:00Z

Passkeys are a new authentication method that is resistant to phishing and easy to use even for non-tech-savvy users, and are said to eventually replace passwords. In this article, we'll summarize the basics of passkeys and what they mean for the future of the web.

What is a passkey? #

On December 9, 2022, Google announced that Chrome for Android now supports passkeys. Apple has also already added support for passkeys in Safari on the latest versions of macOS Ventura and iOS/iPadOS 16.

Passkey is the name of the FIDO credential jointly used by Apple, Google, and Microsoft. The brand and icon "Passkey" were decided upon to allow end users to recognize it as a password-less, intuitive way to log in. From a web developer perspective, it can be safely considered an extension of WebAuthn (Web Authentication), defined by the FIDO Alliance and W3C. In this article, "Passkey" is replaced with "FIDO credential." I previously wrote an article about FIDO and WebAuthn, so if you haven't already, I recommend you read it.

At first glance, a passkey is a biometric login experience, but if you're a techie, it's worth knowing what's going on behind the scenes.

User Experience #

Before users can log in with a passkey, they must create one for each site.

When you try to create or register a passkey, a biometric authentication dialog box will pop up and you will be asked to perform local authentication. Once authentication is complete, a new passkey will be created.

When you log in, an account selector will be displayed. Select the account you want to use and tap to perform local authentication and complete the login process.

The passkey is synchronized, so it can be used on other devices. If the environment does not allow passkey synchronization, you can log in across devices.

When logging in, the browser will display a menu like "Log in on another device." Tap this to display a QR code. Scanning it with your smartphone will perform local authentication, and once complete, you will automatically be logged in on your desktop.

Chrome will remember your device, so you can tap the device name to specify it without having to scan the QR code the second time. Of course, if you create a new passkey on your desktop after that, you'll be able to log in even without your smartphone.

You can try it out for yourself by watching the demo here.

Why passkeys are better than passwords #

Passkeys are phishing resistant #

The domain of the site where the passkey was created is stored as metadata along with the credentials. Therefore, authentication cannot be performed unless the domain matches. This makes phishing virtually impossible, and also has the benefit of freeing users from having to worry about URLs.

Passkey authentication is done locally #

Local authentication with a passkey is resistant to remote attacks.

When you create a passkey or log in with it, you authenticate using the same method you use to unlock your device's screen lock: fingerprint, facial recognition, or a PIN or pattern on Android; Touch ID, Face ID, or a passcode on iOS/iPadOS; Touch ID or a password on macOS; and Windows Hello or a PIN on Windows. This authentication occurs on the user's device, rather than sending credentials directly to the network, and is called "local authentication."

When you create a passkey, local authentication triggers the creation of a new public key pair, with the private key stored on the device and the public key stored on the server. The passkey essentially refers to this private key and its metadata. The passkey is then synchronized and can be used on other devices.

With a password, remote authentication is performed by sending the string entered by the user to the server, but with a passkey login, local authentication is triggered to generate a signature, which is then sent to the server. The server then verifies the signature using the public key stored when the passkey was created, and authenticates it.

Have you noticed that authentication is performed twice in total: local authentication and signature verification on the server? In other words, the passkey alone performs two-factor authentication: biometric authentication (or knowledge authentication) and possession authentication. This is because, unlike a password, a passkey is strong on its own, is difficult to leak, and cannot be reused.

Passkeys can be synchronized across devices #

The greatest feature of Passkey is that it can be synchronized across devices.

With traditional FIDO, credentials created on one device could only be used on that same device. This meant that remote attacks were impossible, meaning that an attacker had no power unless they had physical access to the target device. However, this posed problems in terms of both usability and security when migrating to a new device. Passkey synchronization completely solves these problems.

However, passkey synchronization is limited to within the same ecosystem. "Same ecosystem" refers to the password managers and other mechanisms of each platform, such as those of Google, Apple, and Microsoft. For example, passkeys are synchronized via iCloud Keychain for Apple and Google Password Manager for Google (it is unclear whether Microsoft will officially support passkeys as of December 2022).

Because Apple is vertically integrated, Safari won't work on devices other than Apple devices, and all syncing is primarily based on your Apple ID via iCloud Keychain. Google Chrome syncs between Android devices using Google Password Manager based on your Google Account, but passkeys aren't synced on other operating systems. Google has stated that it plans to sync passkeys using Apple and Microsoft's ecosystems once their sync APIs are available.

Android has also stated that it will support third-party password managers syncing passkeys in the future, so password managers that have announced passkey support, such as 1Password, may become available on Android.

Account selector can be used #

Although technically this feature has been available in Safari and desktop Chrome for some time, Android's support for it has made the account selector feature a prime example of passkey usage. In WebAuthn, this is called Discoverable Credentials (formerly Resident Key), and it stores user information as metadata in the passkey, enabling the account selector UI. Users can log in simply by tapping to select an account and using local authentication, without having to type their username. This significantly improves usability for users who often forget their usernames, let alone their passwords.

This is the feature that allows you to log in using your smartphone, which was explained in the user experience section.

Google Accounts have long had the ability to register your smartphone as a security key for two-factor authentication. This feature is FIDO-compliant and has been expanded to include more than just Google Accounts. This is the feature that lets you log in from another browser via a QR code. It was previously called caBLE, but has now been renamed hybrid.

Because Hybrid was originally intended as a standard, a similar feature was implemented in Safari at the same time as Passkey, allowing you to log in to Safari on macOS using your Android device, and to log in to Chrome on Windows using your iPhone.

Google's two-factor authentication has a similar feature, send a push notification to allow login, but it's its own unique mechanism.

Passkey Considerations #

Privacy #

When a website suddenly requires biometric authentication, I think many end users wonder where their fingerprint or facial information goes. Especially as passkeys become more common and users are still getting used to them, it's only natural to feel fear that fingerprint or facial information might be collected and monitored, or that it could fall into the wrong hands if the service is hacked and leaked.

FIDO has a rule that biometric information must be stored on the authenticator device and must not be sent to a server, etc., so you can rest assured that this rule will be observed at least as long as you use a FIDO Certified authenticator (this includes Android. iPhones are probably included as well, but I couldn't find the source).

Additionally, the information used to create a passkey and passed to the service is a public key and a credential ID, both of which are meaningless byte sequences issued per site. The credential ID is used to limit the authenticators that can be used during authentication and to search for a public key that matches the signature authenticated by the server. The public key is used to verify the signature sent during authentication. Therefore, unless the passkey is registered in combination with personal information such as the user's email address or name, it is not possible to track users across sites using the passkey.

Passkeys may be an authentication method that poses a high psychological hurdle for end users, especially in the early stages, so I think service providers need to provide reassuring measures that address this.

Is passkey synchronization the right thing to do? #

FIDO is based on possession authentication using public key cryptography. The key point is that it is difficult to break the authentication unless you have physical access to the authenticator. However, passkeys can be synchronized and used on multiple devices. This has raised concerns that this could deviate from AAL3 (Authenticator Assurance Level 3) defined in NIST SP800-63B.

However, if we only accept credentials that are tightly bound to the device, when migrating to a new device:

You must transfer all accounts for which you have created credentials.
You must log in to your new device using a non-FIDO method that is vulnerable to phishing.

There are problems such as:

Leaving aside the question of continuing to use passwords, the question is whether to choose traditional FIDO credentials, which are inconvenient and leave authentication methods vulnerable to phishing, or passkeys, which are more convenient but pose slightly increased risks. I think it's best to choose based on your needs.

For example, for consumer services such as social media or news apps, the economic damage would not be so great even if an account were to be hijacked, so it would be wise to choose the convenience of a passkey.

On the other hand, enterprises that handle confidential information, or banks and wallet apps that handle money, may want to keep their devices linked to their devices even if it is slightly less convenient, as there is a possibility of significant economic damage.

In Chrome, if you enable Discoverable Credentials and create a passkey, it will be synced, but if you disable it and create a passkey, it will not be synced as a traditional FIDO credential. In Safari, all credentials are synced as passkeys, which may make it difficult to use in enterprises (perhaps the solution is to use a security key for two-factor authentication).

Device Public Key #

Another option proposed is the Device Public Key Extension, which combines the advantages of a passkey and a device-bound FIDO credential. This creates another device-specific public key pair along with the passkey, allowing the server to detect whether the passkey is already registered on the device. It is expected that this will combine the advantages of both the ease of use of a passkey and the advantages of a device-bound FIDO credential.

However, while Device Public Key is currently planned for implementation on Android, there has been no announcement yet as to whether it will be available on Apple devices. We will be keeping an eye on future developments, including Microsoft's actions.

summary #

With the introduction of Passkey, FIDO has finally entered the practical stage. In addition to the issues mentioned above, there are still issues remaining, such as Firefox not supporting it and the need for further improvement in the synchronization environment, but these are likely to be resolved with time. Some services, such as PayPal and Yahoo! JAPAN, have already deployed it in practice.

Here are some resources:

Official Google documentation: Passwordless login with passkeys
Official Apple documentation: Authenticating a User Through a Web Service
Create a passkey for passwordless logins
Sign in with a passkey through form autofill

We expect the implementation of Passkey to accelerate even further in 2023.

DevFest & Android Dev Summit Japan 2022 will be held #

Finally, a little promotion: DevFest & Android Dev Summit Japan 2022 will be held at the Google office this Friday, December 16th. In addition to web, there will be many sessions on Flutter, Firebase, and Android.

Just for the web section, we have an impressive lineup of speakers scheduled to speak, including Google Developers Experts Yoshiko and Yagura, Chrome team PM Kenji Baheux, Chrome Developer Relations team lead Paul Kinlan, and teammates Milica Mihajlija, Adriana Jara, and Jhey Tompkins. I'll also be talking about passkeys, the subject of this article.

If you have any in-depth questions about any of the sessions, please come and talk to us in person. Since it's a hybrid event, you can also watch the live stream by registering here. We look forward to seeing you there!

Photo by Filip Szalbot on Unsplash

SharedArrayBuffer and the transitional story of cross-origin isolation

2021-11-04T00:00:00Z

2021/12/26: Safari also now supports SharedArrayBuffer using COOP/COEP from version 15.2, so we have changed the notation in the relevant section.

This is a long article, so I'll start with the conclusion.

Chrome, Firefox, and Safari now support SharedArrayBuffer and high-resolution timers. To do so, enable cross-origin isolation, which sends the following two headers to the parent HTML document:

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

However, there are various conditions and restrictions to enable this, and many sites will struggle at this stage. If you just want to continue using Chrome as usual for the time being, it may be a safe option to sign up for the Deprecation Trial and see how it goes for a while.

Spectre threats, browser countermeasures, and site isolation

In our previous article, we discussed the Spectre threat, which exposes cross-origin resources by inferring the memory space used by the same process. We noted that browsers have mitigated the risk by disabling SharedArrayBuffer or reducing the precision of high-resolution timers. We also noted that some browsers have implemented a more fundamental solution by introducing an architecture called Site Isolation. We also noted that standardized features can isolate resources from cross-origin page attacks and ensure their safety. Specifically, various HTTP headers, such as CORP, X-Content-Type-Options, X-Frame-Options, CSP frame-ancestors, and COOP, are used to protect resources before they reach the renderer process.

Browsers that adopt Site Isolation can now use SharedArrayBuffer and high-resolution timers again, but even if all browsers support Site Isolation, is it healthy for the web if these features are only available or unavailable depending on the architecture?

That's where cross-origin isolation comes in. It's a combination of HTTP headers that allows the browser to determine that it is in a safe environment (cross-origin isolated) from other origins, enabling things like SharedArrayBuffer and high-resolution timers.

This article explains how to enable cross-origin isolation, the challenges it poses, and next steps.

What is possible in a cross-origin isolated environment? #

Enabling cross-origin isolation allows you to:

For a while, Chrome introduced Site Isolation to enable the use of SharedArrayBuffer and high-resolution timers, but starting with Chrome 92, this requirement was removed (changing the conditions to be the same as other browsers) and the condition was changed to require cross-origin isolated mode (we're sorry for the inconvenience this caused](https://developers.google.com/search/blog/2021/03/sharedarraybuffer-notes?hl=ja)).

Enabling cross-origin isolation using standardized techniques #

There are currently two conditions for enabling cross-origin isolation, a secure environment where web pages are completely isolated from other origins:

Condition 1. The HTML document sends the `Cross-Origin-Opener-Policy: same-origin` header #

When a browser opens a new window with window.open(), it maintains communication using postMessage() etc., so it uses the same process even cross-origin. In our previous article, we discussed how using COOP headers to separate processes and prevent Spectre We have introduced a method to avoid this threat. If you set COOP: same-origin, the opened window will be opened in a separate process unless it is of the same origin, ensuring safety.

Cross-Origin-Opener-Policy: same-origin

However, it should be noted that this means that communication using postMessage() will no longer be possible.

This is condition 1 for enabling cross-origin isolation.

Condition 2. The HTML document sends the Cross-Origin-Embedder-Policy: require-corp header

The header Cross-Origin-Embedder-Policy (COEP), which was not mentioned in the previous article, is not intended for security purposes in itself. COEP eliminates all embedded resources that are not permitted, thereby eliminating exposed resources and achieving cross-origin isolation. Specifying COEP: require-corp will block all resources that are not explicitly permitted by CORS or CORP from being loaded on this page.

Cross-Origin-Embedder-Policy: require-corp

This is condition 2 for enabling cross-origin isolation.

Check for cross-origin isolated #

You can check whether a web page that sends the above two headers is cross-origin isolated by checking self.crossOriginIsolated. If it returns true, it is cross-origin isolated, and if it returns false, it is not.

if (self.crossOriginIsolated) {
  // The environment is cross-origin isolated.
} else {
  // The environment is NOT cross-origin isolated.
}

You can try out cross-origin isolation in this demo.

Resources are blocked!? #

It would be very easy if it ended here, but the difficult part begins from here. If you have actually tried cross-origin isolation, you will notice that this alone completely breaks normal websites. This is because all cross-origin resources that do not have special treatment are blocked. To load cross-origin or same-site cross-origin resources, you need to explicitly configure CORS or CORP to indicate that it is okay for them to be loaded from cross-origin.

Reference: Understanding same-site/cross-site, same-origin/cross-origin

Add CORS or `Cross-Origin-Resource-Policy` headers to resources #

"Resources" here refers to anything that can be loaded from an HTML document, such as documents, images, videos, fonts, scripts, styles, etc.

As mentioned in our previous post, CORP indicates that resources can only be loaded from the same origin (same-origin), same-site (same-site), or any origin (cross-origin).

For example, if https://www.example.com sends COEP: require-corp, the condition for loading an image is CORS-enabled, or:

If it is served from the same origin, it will be loaded unconditionally (CORP: same-origin may be specified).
If it is served from the same site (e.g. https://images.example.com/image.png), it will be loaded if it has CORP: same-site or CORP: cross-origin. Otherwise it will be blocked.
If it is served from a completely different site, it will be loaded if it has CORP: cross-origin. Otherwise it will be blocked.

Cross-Origin-Resource-Policy: cross-origin

If you want to use CORS, you need to require it when loading a resource, for example by adding the crossorigin attribute to the <img> tag to send a CORS request.

<img src="***/image.png" crossorigin>

crossorigin attribute can be added to <audio>, <img>, <link>, <script>, <video> tags

You can try out the combined functionality of COEP and CORS/CORP in this demo.

Add COEP to the HTML document loaded in the iframe #

As I mentioned in my previous article, HTML documents loaded in an iframe are also vulnerable to the Spectre threat if they are cross-origin. But what happens if that cross-origin HTML document also loads other cross-origin resources or documents?

In fact, if you don't meet the requirements recursively, everything will be blocked. Embedding an iframe requires that it itself has COEP: require-corp .

In summary, if you embed a cross-origin HTML document in an iframe on a cross-origin isolated page, the HTML document loaded in that iframe must also:

Must be COEP: require-corp
Must be CORP: cross-origin (CORP: same-site is also acceptable for same-site/cross-origin)

It will be.

In this case, self.crossOriginIsolated within the iframe will become false, but by specifying allow="cross-origin-isolated" in the iframe tag, it will become true, allowing you to use SharedArrayBuffer etc.
There may be cases where you want to enable cross-origin isolation only within an iframe, but unfortunately there is no way to do this. All frames on the same page must be part of the cross-origin isolation of the parent frame.

You can also try out the iframe demo here:

The above is already supported by all major browsers: Chrome, Edge, Firefox, and Safari.

Challenges of cross-origin isolation and solutions #

If you follow the above steps completely, you will have SharedArrayBuffer etc available in your browser.

However, there are still challenges remaining.

**Issue 1. COOP: same-origin breaks integrations that use popup windows, such as OAuth and payments. ** Due to the nature of COOP: same-origin, integrations that often involve opening cross-origin windows for communication, such as OAuth and payments, become impossible.
**Issue 2. Even if you try to specify CORS or CORP: cross-origin, you can't do so because they are resources from other companies. ** This is also a typical problem with cross-origin isolation.

For example, while many resources delivered by Google already support CORP: cross-origin, some services do not support cross-origin isolation due to the challenges mentioned above. For example, Google Ads delivers ads using iframes, but in some cases the content of the iframes is delivered by the advertiser. Since it is not realistic to require all of them to implement CORS or CORP, they have indicated their intention not to support it.

In light of these developments, discussions are underway to re-enable SharedArrayBuffer in Chrome without cross-origin isolation, and to relax the conditions for enabling cross-origin isolation from the standard specification side.

Enabling `SharedArrayBuffer` without cross-origin isolation in Chrome #

I explained that Chrome originally supported an architecture called Site Isolation, and that the transition to cross-origin isolation was made to align with other browsers. However, due to the issues mentioned above, there is also an option to continue using SharedArrayBuffer without supporting cross-origin isolation. By applying a mechanism called Deprecation Trial, you can continue to use SharedArrayBuffer as before, at least until the improvements described below are ready.

Reference: SharedArrayBuffer updates in Android Chrome 88 and Desktop Chrome 92

As of November 2021, the deprecation trial can be used to avoid the issue up to Chrome 103, but if the following improvements are not implemented in time, it may be extended. If you signed up for the Origin Trial, you will be notified by email whether the trial will be extended, but we will update the blog post above (even if this blog post is not updated).

To sign up for a deprecation trial, apply here and specify your origin and distribute the issued token in the Origin-Trial header or <meta> tag on your site. For more information, see Introduction to Chrome Origin Trials, which has just been translated into Japanese.

Relaxing cross-origin isolation requirements #

Efforts are also underway to make cross-origin isolation more flexible from a standardization perspective. We will introduce the proposed specifications for this purpose.

`COEP: credentialless` #

The challenge is that it is difficult to require resources provided by other services to comply with CORS or CORP, but is that even necessary? Many resources are images, styles, fonts, and other resources that are publicly available on the Internet. Anyone can download them if they know the URL, so authentication should be required to protect them.

So, instead of requiring CORS or CORP as a COEP mode, it would be better to create a mode that assumes requests are made without authentication, and that's how COEP: credentialless was devised.

Cross-Origin-Embedder-Policy: credentialless

COEP: credentialless omits authentication methods such as cookies, client certificates, and Authorization headers from requests to the server, allowing you to enable cross-origin isolation without exposing third-party resources to risk.

Even in the case of COEP: credentialless, you can explicitly send authentication information by adding the crossorigin attribute to the request.

Reference: Load cross-origin resources without CORP headers using COEP: credentialless

Only available in Chrome from version 96.

anonymous iframe #

Following a similar approach, we are considering an anonymous iframe method that does not send authentication information to iframes, thereby not putting third-party resources at risk. However, due to the complexity of iframe architecture, the specifications are currently under development.

`COOP: same-origin-allow-popups-plus-coep` #

A mitigation is also being considered for the issue where using COOP: same-origin breaks popup window integrations such as OAuth and payments. The idea is that using COOP: same-origin-allow-popups allows communication with windows opened from your own origin, so it might be a good idea to make this a condition for cross-origin isolation.

A dedicated mode for this purpose, COOP: same-origin-allow-popups-plus-coep, is being considered, but is still in the early stages of development.

summary #

This article has explained how to enable cross-origin isolation in browsers and use SharedArrayBuffer and high-resolution timers, but it's quite complicated and requires a lot of thought.

If you want it to work on Firefox or Safari right away, you could consider giving up on cross-origin resource integration to some extent and enabling cross-origin isolation. However, if you just want it to work on Chrome as usual for the time being, the best option for now is to sign up for a deprecation trial and see how it goes for a while.

The content explained in this article was released as a session video at the Chrome Dev Summit in 2020.

Finally, on November 17th, as part of the Chrome Dev Summit, we will be hosting a one-hour workshop that will explain the journey from Spectre to Site Isolation and cross-origin isolation.

Gain security and powerful features with cross-origin isolation

If you have any questions, please feel free to join us (sessions will mainly be in English).

Reference articles #

The Spectre threat and the headers websites should set

2021-11-01T00:00:00Z

This is a long article, so I'll start with the conclusion.

The emergence of Spectre has increased the security requirements for websites. Specific measures required are as follows:

All resources should use the Cross-Origin-Resource-Policy header to control loading into cross-origin documents.
HTML documents should include the X-Frame-Options header or the Content-Security-Policy (CSP) header with the frame-ancestors directive to control embedding in an iframe in a cross-origin page.
HTML documents should include the Cross-Origin-Opener-Policy header to control communication with cross-origin pages when opened as a popup window.
All resources should include appropriate Content-Type and X-Content-Type-Options: nosniff headers to prevent malicious cross-origin loading.

To understand why such a header is necessary and to understand the details, we first need to look at how modern browsers display web pages.

A look back at how browsers work #

Each tab in a browser has a URL that tells the user which page they are currently viewing. The URL displayed in a tab usually points to an HTML document, which represents the entire web page by loading various resources such as images, videos, stylesheets, scripts, and fonts. In this case, the domain of each resource does not necessarily match the domain of the currently viewed page.

In this case, the domain displayed in the URL bar is called the "first party," and any domain other than the first party of the loaded resource is called the "third party." (So, a "third-party cookie" is a cookie associated with a third-party resource.)

Regarding the relationship between two domains, if only the eTLD+1 (effective Top Level Domain and the one above = e.g. example.com) is the same, it is called same-site; if the scheme, hostname, and port number all match (e.g. https://www.example.com:8080), it is called same-origin; otherwise it is called cross-site or cross-origin.

In the rest of this article, we will explicitly use same-site/cross-site and same-origin/cross-origin, so if you are unsure about the difference between them, please start here.

Reference: Understanding same-site/cross-site, same-origin/cross-origin

The Web's greatest appeal is its composability, which allows you to combine various resources from different domains (services) like a puzzle to create rich expressions. Especially since Web 2.0, the concept of APIs has been added to this and further developed. For example:

Implement analytics simply by loading a script and analyze or track the behavior of users who visit your site.
Use iframes to embed information from external sites as widgets, and embed ads, social media buttons, personalizable maps, and videos.
Communicate with external sites via popup windows to enable integration such as login and payment.

Cross-origin collaboration is what makes the web the web.

Same-Origin Policy #

By the way, one of the scary things about the online world is that information that you thought you had entrusted to the right place could end up in a place or be used by someone you didn't intend. This is especially serious if that information is credit card numbers or bank account information. In a web browser, the "right place" is represented in the form of a domain, and its reliability is guaranteed by using HTTPS.

Attackers can steal information from three main points: browsers, networks, and servers. Browser attacks can also be said to involve crossing domain barriers. The Same-Origin Policy allows different domains to communicate with each other on a browser while still maintaining a certain level of security for each site. This policy is based on a delicate balance between maintaining mutual inviolability at the origin boundary, while allowing some degree of communication.

Let's take an embedded video as an example. This cross-origin video is embedded in an iframe, allowing for personalization using third-party cookies. If the user is logged in to the hosting domain, they can access the account and perform actions like "watch later," which is convenient. However, unless a specific API is provided, the embedding site cannot access this account information. This is because navigating the DOM tree of the window object obtained from the iframe only provides limited information. It is impossible to see what HTML is being displayed, let alone the contents of cookies.

The same applies to windows opened as popup windows. For example, if a typical payment service is linked to a window opened using window.open() and the DOM tree is accessible, the store could eavesdrop on the user's credit card information. For this reason, browsers limit the information that can be accessed from the return value of window.open() and from window.opener of the opened window.

In this way, the browser's Same-Origin Policy prevents cross-origin scripts from accessing arbitrary information.

By the way, when you research Cross-Origin Resource Sharing (CORS), most articles describe it as "a mechanism for requesting resources hosted on cross-origin sites using fetch()." While that's true, not all of them are. In fact, CORS also plays a role in access control on the browser.

For example, when loading a cross-origin image into your page, you can simply use the <img> tag and not worry about CORS. There's no problem if the image is displayed on the page at the specified size and the user can view it. However, in this case, the browser uses the Same-Origin Policy to protect the image's contents (binary) from being viewed by cross-origin scripts. This is called an Opaque Response.

For example, if you try to get the binary of an image loaded from a cross-origin browser, and then try to retrieve it as canvas, drawImage() and then getImageData(), Chrome will display the error DOMException: Failed to execute 'getImageData' on 'CanvasRenderingContext2D': The canvas has been tainted by cross-origin data. and fail. This is because the browser is protected by the Same-Origin Policy.

To enable this, you must explicitly allow it by specifying the <img> attribute with the crossorigin attribute and by supporting CORS on the server side.

I've created a simple demo, so give it a try.

In this way, the Same-Origin Policy ensures the security of the web to some extent by allowing browsers to control access between origins.

What is the Spectre threat?

Spectre is a vulnerability in the architecture of CPUs that was announced in 2018. Simply put, it allows values in memory space controlled by the same process to be inferred. Spectre makes it possible for cross-origin scripts to spy on resources that transcend the Same-Origin Policy, which poses a major threat given the nature of the web.

Once malicious JavaScript was loaded, an attacker could bypass the Same-Origin Policy and read any DOM element running in the same process. With the architecture of most browsers at the time, simply loading resources via an attacker's page could result in information theft. If the resources included authentication information or other information requiring authentication, even that information could be compromised.

Measures taken by each browser #

Spectre's ability to efficiently steal information by leveraging high-resolution timers has led browser vendors to disable functions related to high-resolution timers. A prime example of a function that became unavailable as a result of this was SharedArrayBuffer. Other measures taken included reducing the accuracy of performance.now(). However, these measures only reduced efficiency, and Google research has shown that completely eliminating the threat of Spectre would require fundamental changes to the browser's architecture.

Site Isolation #

That's where Site Isolation comes in. Site Isolation was a project the Chrome team had been working on since before Spectre became known, to mitigate the risk of exploiting memory bugs to bypass the Same-Origin Policy. The discovery of Spectre accelerated the completion of this architecture, and it was released experimentally in May 2018.

Chrome originally created processes roughly on a tab-by-tab basis, but Site Isolation, as the name suggests, separates processes on a site-by-site basis to isolate cross-site resources and protect against Spectre threats. Specifically, it uses techniques such as Cross-Origin Read Blocking (CORB) and Out-of-process iframe (OOPIF). For more information, see the Site Isolation page.

Actually, it would be more correct to say "separate the Browsing Context Group" rather than "separate the process," but for convenience we use the word "process" here.

Dividing processes into smaller ones incurs overhead, increasing memory consumption by about 10%, making it unsuitable for resource-scarce mobile devices. For this reason, Site Isolation is generally only enabled in desktop environments and for some mobile sites. This is why SharedArrayBuffer was available only in the desktop version of Chrome for a while.

The problem is that Site Isolation is a Chrome-specific architecture. Firefox is currently working on a project called Fission to introduce a Site Isolation architecture, but the web is built on standard technologies, so security cannot be guaranteed by assuming a specific architecture.

This is where the main topic comes in: HTTP response headers that require the browser to handle cross-origin resources appropriately, regardless of the browser architecture, such as by routing them to a separate process.

Preventing Spectre attacks before they happen #

To prevent Spectre attacks, you need to stop resources from your origin before they are pulled into the same process as a malicious origin. By looking at the HTTP response headers, the browser's network process can block the resource before it is passed to the malicious origin's renderer process, or pass it to a different renderer process.

If you open Chrome's Task Manager, you can see how processes are grouped by Process ID.

The four HTTP response headers that should be added are:

Cross-Origin-Resource-Policy
X-Frame-Options or CSP frame-ancestors
Cross-Origin-Opener-Policy: same-origin-allow-popups
Content-Type and X-Content-Type-Options: nosniff

Controlling resource embedding with `Cross-Origin-Resource-Policy` (CORP) #

You can allow resources to be loaded from same-origin, same-site, or from anywhere with cross-origin, such as images, videos, audio, scripts, and JSON via API. For example, adding the respective headers to an image hosted in https://images.example.com will result in the following:

Cross-Origin-Resource-Policy: same-origin

This image can only be loaded from an HTML document served from the same-origin https://images.example.com.

Cross-Origin-Resource-Policy: same-site

This image can be loaded from domains containing the same-site example.com, e.g. https://www.example.com, but not from other eTLD+1s, e.g. https://site.example.

Cross-Origin-Resource-Policy: cross-origin

Added 2021/11/04: It was originally written as cross-site, but it was a mistake and should have been cross-origin.

Images with the default cross-origin can be loaded from any origin, not just https://images.example.com or example.com.

You can try these headers out in this demo. Open DevTools and see the impact of the Cross-Origin-Resource-Policy header.

CORP is already supported in Chrome, Firefox, and Safari.

Please note that CORP does not prevent a resource from being served. It is not like an ACL (Access Control List) on the server, and does not determine whether a resource will be served in response to a request from a browser that does not support CORP, or from another server, or from an HTTP client that is not a browser.

CORS is similar to CORP, but differs in that it allows for more granular determination of conditions and can choose not to serve requests depending on the origin (Preflight Request).

Note that it's not a problem if publicly available resources are stolen. What's problematic is information served when authenticated, which often requires a third-party cookie. If you set the appropriate SameSite attribute, even if you fall victim to Spectre, no authenticated requests will be sent.

Fortunately, the default SameSite attribute for cookies in Chrome and Edge is Lax. If you are a service provider who has inadvertently set SameSite to None, we recommend that you review your settings in conjunction with the introduction of the CORP header.

Control document iframe embedding with `X-Frame-Options` or CSP `frame-ancestors` #

As of October 2021, all browsers allow embedding HTML documents in iframes by default, and resource providers must take appropriate action to prevent this.

To prevent cross-origin sites from loading in an iframe, you can either block them entirely using the X-Frame-Options header, or explicitly specify which origins are allowed to be embedded using the frame-ancestors CSP (Content Security Policy) header directive.

X-Frame-Options: DENY

HTML documents with DENY will not be loaded in an iframe regardless of the parent page's origin. You can also set this to SAMEORIGIN to load in an iframe only if the parent page is the same-origin.

Content-Security-Policy: frame-ancestors 'self' https://www.example.com;

An HTML document with the above CSP specified will not be loaded in an iframe unless the parent page has the same origin as the original or is https://www.example.com.

It is recommended that all documents that are not intended to be loaded in an iframe use X-Frame-Options: DENY.

Both X-Frame-Options and CSP frame-ancestors are already supported by Chrome, Firefox, and Safari.

Controlling communication between windows with `Cross-Origin-Opener-Policy` (COOP) #

Windows opened using window.open() can communicate with each other using postMessage(). In this case, even if the browser is cross-origin, it is deployed in the same process, making it vulnerable to Spectre attacks.

By using the Cross-Origin-Opener-Policy (COOP) header, you can ensure safety by separating processes when opening cross-origin windows. However, please note that in this case, communication using postMessage() will no longer be possible.

Cross-Origin-Opener-Policy: same-origin

If you specify same-origin, even if you open a cross-origin popup window yourself or if a document from your origin is opened from a cross-origin window, they will be in separate processes and communication will be impossible.

Cross-Origin-Opener-Policy: same-origin-allow-popups

same-origin-allow-popups separates processes when opened from a cross-origin window, but not when you open the cross-origin window yourself (however, the cross-origin window must not specify COOP or must specify unsafe-none).

Cross-Origin-Opener-Policy: unsafe-none

unsafe-none is the default, and can be used to specify that a separate process is not required when opening a cross-origin window or when opening a cross-origin window (provided that the cross-origin window does not specify COOP or specifies unsafe-none).

You can try out these headers in this demo:

Similar to Cross-Origin-Opener-Policy: same-origin is a[rel="noopener"]. This also serves to avoid the risk of Spectre, which occurs because new windows opened with the <a target="_blank"> tag are opened in the same process by default. Fortunately, rel="noopener" has now been changed to the default in Chrome, Firefox, and Safari, so you no longer need to worry about it. Conversely, to achieve the same result as Cross-Origin-Opener-Policy: unsafe-none, specify rel="opener".

Reference: Preventing Tabnabbing by Adding rel=noopener to Links | blog.jxck.io

While COOP can protect your site from Spectre attacks from cross-origin windows, you still need to be careful with pages that use features that require cross-origin windows to be opened, such as OAuth or payment functions. We recommend adding Cross-Origin-Opener-Policy: same-origin-allow-popups to all HTML documents. (For debugging instructions, see Making your website "cross-origin isolated" using COOP and COEP // Debug issues using Chrome DevTools.)

COOP is already supported in Chrome and Firefox, and it appears that support for Safari will be coming soon (as of October 2021).

Protect resources from malicious cross-origin loading with `X-Content-Type-Options: nosniff` #

Some browsers may automatically change the MIME-Type from the resource content and load it into the page, even if Content-Type is set, which is a known vulnerability. This can be used as a means to load resources into the same page process, making it applicable to Spectre attacks. Specifying X-Content-Type-Options: nosniff will prevent the browser from doing this. Be sure to specify the appropriate Content-Type header and X-Content-Type-Options: nosniff.

X-Content-Type-Options: nosniff

X-Content-Type-Options is available in all browsers, including IE.

A story of the future #

I've tried to simplify this complex topic as much as possible, but I don't think it's realistic for every web developer to understand and implement these headers. It would be great if browsers could do it automatically. But that would mean completely reversing the current default behavior, which is:

Disable embedding of cross-origin HTML documents by default = X-Frame-Options: DENY default.
Disable communication with cross-origin popup windows by default = Cross-Origin-Opener-Policy: same-origin-allow-popups default.

The Chrome team is working to make this a reality, but reversing the default is a disruptive change. We understand that this is an unavoidable step in making the web a safer place, and we hope that as many developers as possible will understand this and begin preparing little by little.

Additionally, the content explained in this article will be made available as a session video at Google I/O 2021. It will also have Japanese subtitles, so please take a look.

This article touched on some of the HTTP headers related to Spectre, but there are a few other important ones. Please refer to this page for a summary.

Security headers quick reference:

Also, Mike West's Post-Spectre Web Development is a more practical take on the topics discussed in this article, broken down by use case.

Post-Specter Web Development

*The illustrations for this article were created by @kosamari.

Introducing WebAuthn DevTools

What is WebAuthn DevTools? #

Summary #

Key terminologies to get a grasp of passkeys

Standards #

FIDO #

U2F #

UAF #

FIDO2 #

WebAuthn #

Basics #

Authenticator #

Relying Party (RP) #

RP ID #

Discoverable Credentials #

User Verification #

Attestation #

AAGUID #

MDS #

Implementation #

excludeCredentials #

Conditional mediation #

Signal API #

Related Origin Request #

getClientCapabilities #

Client Hints #

Passkey endpoint #

Conditional creation #

Immediate mediation #

Finally #

Renewed the blog system

Background of the renewal #

Main changes #

1. Multilingual support (i18n) and URL structure changes #

2. Automatic translation using Google Cloud Translation API #

3. Infrastructure Changes: Migrating to Cloud Run #

4. Introducing organicity #

Future outlook #

I wrote a book called "All About Passkeys."

A collection of basic information that PMs and designers need to know #

Contains the essentials that engineers need to know to implement passkeys #

Packed with information for advanced users #

lastly #

Tips for using your passkey

Passkey Basics #

What makes passkeys difficult to use? #

Passkey not found #

1. The passkey provider that saved the passkey cannot be accessed from the new environment. #

2. The passkey provider is available, but you can't access the account where the passkey is stored #

3. The passkey provider's passkey is not synchronized in the first place #

Created a passkey for Windows Hello #

You created a passkey in iCloud Keychain on macOS, iOS, or iPadOS and tried to access the passkey from a non-Apple device #

I created a passkey for a service that I don't want to sync #

4. The biometric authentication feature you thought was a passkey is actually not a passkey #

5. I can't log in because the service doesn't offer any authentication method other than a passkey #

Tips for users to master passkeys #

Tip 2: Be aware of which passkey provider you store your passkeys with #

Windows #

macOS #

iOS/iPadOS #

Android #

Linux #

ChromeOS #

Third-Party Passkey Providers #

Tip 3: Create passkeys for multiple passkey providers #

Services that can make passkeys more convenient to use #

Let users know which passkeys cannot be synced and which passkey providers they use #

Adjust passkey promotion frequency #

Guide to authentication methods other than passkey #

Change behavior for each environment #

Follow the guidelines #

summary #

The basics of passkeys and clearing up misconceptions surrounding them

Passkey Basics #

Clearing up misconceptions about passkeys #

Myth 1: Using a password manager is enough to keep me safe, so there's no point in using a passkey #

Myth 2: If I lose my device, will my passkey become useless? #

Misconception 3: If I use a passkey, can someone steal my account? #

Myth 4: I don't want to use a passkey because it would make me completely dependent on Big Tech for my valuable authentication. #

Myth 5: If my password manager account is compromised, all my passkeys are compromised too #

Condition 1. The HTML document sends the `Cross-Origin-Opener-Policy: same-origin` header #

Add CORS or `Cross-Origin-Resource-Policy` headers to resources #

Enabling `SharedArrayBuffer` without cross-origin isolation in Chrome #

`COEP: credentialless` #

`COOP: same-origin-allow-popups-plus-coep` #

Controlling resource embedding with `Cross-Origin-Resource-Policy` (CORP) #

Control document iframe embedding with `X-Frame-Options` or CSP `frame-ancestors` #

Controlling communication between windows with `Cross-Origin-Opener-Policy` (COOP) #

Protect resources from malicious cross-origin loading with `X-Content-Type-Options: nosniff` #