Events identity

Summary of "Chrome Tech Talk Night #16 ~ Passkey"

Nat 2024-06-24 No Comments

Chrome Tech Talk Night #2024 ~ Passkey was held at the Google Shibuya office on June 6, 14. CTTN #16 is an event aimed at helping developers learn the basics of passkeys and resolve common questions. Experts from FIDO Alliance member companies who are actively involved in the specification development took to the stage.

The documentation is published here:Chrome Tech Talk Night #16 Passkey

The following is a summary by Claude Sonnet 3.5 and Notta.ai, with some minor edits. I am a novice in this field, so I'm sure there are some mistakes. If there are, I would appreciate it if you could point them out.

Table of Contents

Chrome Tech Talk 16 – About Passkeys #passkeys_jp

1. Introduction

  • Event Name: Chrome Tech Talk 16
  • Subject: Passkey
  • Speaker:
    • Google Developer Advocate: Eiji (@agektmr)
    • NRI SecureTechnologies Co., Ltd.: Hideaki Furukawa (@hdfrk)
    • Mercari: kokukuma-san (@kokukuma)
    • Mercari: Kotaro Oi (Product Manager)@koiPM4)

2. Mercari's Passkey Implementation Case Study (Mr. Oi)

3. Registering a passkey (by kokukuma)

There are two ways to register a passkey: on the same device or on a different device. When using the same device, the passkey is created on the device after biometric authentication. When using a different device, authentication is performed by reading a QR code, and the passkey is created on that device. The role of the parameters required during registration (challenge, RPID, etc.) and the flow of API calls were explained.

user experience

  • There are two user experiences: same-device registration and off-device registration.
  • If you try to register on the same device, you will be asked to provide biometric information etc.
  • If you are using a different device, registration will be completed by reading the QR code on the mobile device and using biometric authentication.
  • Webauthn.io You can see it clearly by looking at the image.

Registration Process

  1. Server Generated Challenge (PublicKeyCredentialCreationOptions)
  2. The browser passes data (rp.Id, User info, RP info, clientDatahash) to the authenticator.
  3. Authenticator for user verification and passkey generation
  4. Send the generated data to the browser
  5. The browser sends the data back to the server
  6. Validate and save on the server

Important parameters

  1. AuthenticatorAttachment and hint
    • Specify the type of authenticator that can be used (e.g. platform, cross-platform)
    • You can also specify combinations that you do not want to display (e.g. security keys in the consumer context).
    • authenticatorSelection.AuthenticatorAttachment: When the RP calls navigator.credentials.create() to create a passkey, it uses this to specify the types of authenticators it will allow to register.
      • eg, “platform”, “cross-platform”
    • Hints (near future): The RP can use this enumeration to convey hints to the user agent about how to best complete the request.
      • eg, “security-key”, “client-device”, “hybrid”
    • The designation depends on the purpose of the RP passkey implementation.
  2. challenge and rp.id
    • Essential parameters for phishing-resistant authentication
    • The range of rp.id and its subdomains will be the range in which the same passkey can be used.
    • As announced at WWDC2024, Safari now supports Related Domains, relaxing this restriction.
    • challenges: A random value created by the server that is associated with the session that started the passkey registration. It is verified when the passkey is registered.
    • rp.id: Specify a valid domain name for user registration and authentication. The registered passkey can only be used for authentication with the RP associated with the registered rp.id.
  3. user.id and excludeCredentials
    • Used to create a single passkey per provider
    • user.id: A value that uniquely identifies a user within the RP. It is different from the identifier the user uses to log in and should not contain any personal information about the user.
    • excludeCredentials: Pass in all registered passkey identifiers to prevent multiple registrations by the same device. If an individually specified passkey already exists, the authenticator will return an error.
  4. user.displayname and user.name
    • Specify what you want to display when selecting an account during authentication
    • user.name: A friendly identifier for the user account, for display purposes only.
    • user.displayName: A friendly name for the user account, for display purposes only. RPs should allow users to choose this name
    • This is a value that will be displayed in Conditional UI, so enter a value that users can see and distinguish.
    • Information that cannot be changed and is unique to your account is best.
    • displayName and name can be the same value...
  5. residentKey / userVerification / attestation

Client side implementation

The result of credentials.create goes into cred, and it is then Base64URL encoded and other processes are performed on it before it is set into credential.response.

Server side implementation

SimpleWebAuthn Example of using. The contents of verifyRegistrationResponse are too long, soCodeschecking ...

There are many verification parameters, but here are two of the most important ones:

CollectedClientData
Information about the authentication request

  • type: webauthn.create
  • challenge: The challenge passed to the authenticator is returned.
  • origin: The origin string passed from the browser to the authenticator.

Verification

  • type is webauthn.create
  • The challenge matches the value stored on the server
  • Verify that the origin is the one you want to allow.

Through this verification, combined with the rp.Id mentioned above, it has become phishing resistant.

attestationObject

  • authenticator data: Information about the authenticator used
  • Flags: Flags indicating the state of the authenticator and the type of authentication.VerificationMake sure UP is set and also make sure UV is set as required by RP.
  • Attestation statement: A specific type of signed data object that contains a public key credential itself and a statement about the certifier who created it, including a certification signature created with the key of a certification authority.Verificationreceives the attStmt, authenticatorData, and clientDataHash and determines whether the attestation statement is valid. In the case of a synced passkey, the attestation statement is not included.

What to store on the server

  • Attested Credential Data
    • Credential ID: You can specify it using excludeCredential, etc.
    • Credential Public Key: To be used to verify assertions during authentication
    • AAGUID: To determine the passkey provider
  • Flags
    • BE: To determine if it is a synced passkey
    • UP/UV: Whether local authentication was performed during registration.

Warnings

  • Many extensions are not fully implemented in browsers or operating systems
  • Conditional Creation: Passkeys can be created without user interaction

4. Overview of Passkey Authentication Flow (by Mr. Furukawa)

In passkey authentication, parameters such as a challenge are received from the server and signed on the device using a passkey. The signature is then sent to the server, where it is verified using the public key. This process was explained in detail, showing how data passes between each component, including the browser, JavaScript app, and authentication device. It was also emphasized that the passkey key itself is not sent to the server, and biometric information is not shared with the server.

Main passkey recall methods

  1. Conditional UI
    • Set the value of webauthn as the autocomplete attribute in an input or textarea form
    • Determine whether Conditional UI is available on the browser
    • Triggers the Conditional UI if it is available
    • Also provides error display when user operation is interrupted
  2. Login with passkey button
    • Execute the passkey script by pressing a button
    • allowCredentials is empty
      • allowCredentials = [];
  3. Password request from ID entry
    • Narrow down the credential ID of the user's passkey from the entered ID
    • Include the credential ID in allowCredentials
      • allowCredentials = [credentialId, credentialId];

Authentication flow overview

  1. User chooses to log in with passkey
  2. The server receives a request to start authentication.
  3. Sends challenge and other data to the browser (PublicKeyCredentialRequestOptions)
  4. The browser passes the data to the authenticator (authenticatorGetAssertion)
    • The input values ​​of authenticatorGetAssertion include rpId and hash, and this hash contains the serialized hash of clientData, which also contains the hash generated by the server.
  5. Authenticator for user verification
    • User verification: Confirming that the authenticator has local permission to generate credentials or obtain assertions (such as a PIN or password, or biometric identification) for the purpose of identifying the user.
  6. Signing with a passkey
    • Concatenate the authenticatorData and clientDataHash and generate an assertion signature using the credential's private key.
  7. The signed data is sent back to the browser
    • At this time, the user identifier is set and returned to selectedCredential.userHandle, so the server knows which user it is.
  8. Send the signed data back to the server (AuthenticatorAssertionResponse)
  9. Validate on the server
    • Verify the signature with the registered public key

Cross-device authentication

Cross-device authentication is a method of authentication in which a passkey is shared between different devices. In this case, a QR code is displayed on the device you are logging in to, and authentication is possible by reading that QR code with another device that has the passkey. A Bluetooth connection is required, and authentication is only possible within a certain distance. The process for cross-device authentication and the operating procedures for each device were explained.

  • Authentication across different devices using QR codes
  • Bluetooth connection required

5. Answers to common misconceptions and questions

  1. The passkey is not sent to the server
  2. Phishing prevention is achieved by RPID and origin check
  3. User verification is not always required.
    • A flag in the authenticatorData that the “Relying Party” JavaScript application sends back to the “Relying Party” server, with Bit 2 indicating whether or not user verification was performed.
  4. Biometric information is not shared with the server
  5. Passkey providers generally cannot see your private key.
  6. You can create multiple passkeys for one account.
  7. What is the difference between a synced passkey and a device-bound passkey?
    • Synced Passkey: Syncable across devices
    • Device-bound passkey: Binds to a specific device only

6. Future prospects

  • Reporting API: A mechanism for reporting changes to user information to the authenticator
  • Use of attestation: Checking security levels and restricting specific devices

The conference covered a wide range of topics, from basic passkey concepts to implementation details and actual deployment examples, providing deep insight into the current state of passkey technology and future challenges.

Q&A

There were also several Q&A sessions during the session.

Q. Why does Mercari require an SMS OTP when registering a passkey?

  1. Enhanced phishing protection:
    • According to Mercari's Ooi, this is a measure to further reduce the risk of phishing.
  2. Leverage existing strong authentication methods:
    • Before registering a passkey, the combination of ID password and SMS OTP is the strongest authentication method.
  3. Defense in depth:
    • Even if your ID and password are leaked in a phishing attack, the additional barrier of SMS OTP reduces the risk of fraudulent passkey registration.
  4. Two-step verification:
    • You can perform SMS OTP verification twice by using your ID password and SMS OTP when logging in, and then requesting SMS OTP again when registering your passkey.
  5. Risk Mitigation:
    • This method reduces the risk of an attacker using phished information to fraudulently register a passkey.
  6. Balancing user experience and security:
    • Ooi says this is a compromise between balancing UX and security.
  7. Service decision:
    • However, not all services use this method, and the need for additional authentication must be determined based on the risk assessment of each service and the path the user takes to register a passkey.
  8. Protecting your existing account:
    • Services, especially those with an established user base, should enforce stronger authentication before passkey registration to reduce the risk of account takeover.

This approach is positioned as one part of a strategy to keep the registration process itself secure when introducing a strong authentication method such as a passkey.

Q: Are there any anti-patterns for passkey implementation that could create vulnerabilities?

A: If you implement everything yourself without using a passkey library and do not verify the origin, it may create vulnerabilities. Also, if you do not verify the public key, it will be a vulnerability. Furthermore, if you do not properly verify the user verification flag (UV), it will increase security risks.

Q: If I enter an email address as the username, can I update the username on the authenticator when a user changes the email address they use to log in?

A: Currently, it is not possible to update the username. However, once the reporting API is implemented in the future, it will be possible for the RP to notify the authenticator of changes to user information and update the username.

Q: What is the difference between a FIDO credential and a passkey?

A: The FIDO Alliance defines any passwordless authentication credential as a passkey. Security keys and UAFs are also included in the passkey category as they are a type of file credential.

Q: I would like to know the difference between Chrome's Password Manager and Passkey in terms of phishing resistance.

A: Password managers store character strings, so if a user copies and pastes them, they can be used on phishing sites. On the other hand, passkeys cannot be copied and pasted, so they are resistant to phishing. Since passkeys cannot be copied and pasted, they cannot be used to log in to sites that are not suggested.

Q: How much freedom do we have in terms of extensions?

A: Extensions cannot be freely specified, as it depends on the functions implemented in the browser and OS. Only extensions listed in the documentation can be used.

Q: Mercari initially only supported device-bound sharing, but now it also supports Synced. Have you encountered any new or unique issues as a result of sharing Synced?

A: The introduction of synced passkeys has created new issues, such as an increase in inquiries from users with improper iCloud settings. We also need to deal with cases where devices are lost. On the other hand, the number of inquiries has decreased compared to device-band passkeys.

Q. I think there is a risk that cross-device authentication could result in the QR code being read from behind. Is it possible to prevent this by specifying CredentialCreationOptions or similar?

A: Not currently possible.

Q: Regarding the use of a passkey with caBLE and Hybrid, is it possible to operate the operating device and the device with the passkey separately? Is a Bluetooth connection required?

A: Yes, Bluetooth connection is required. Passkey authentication cannot be performed on devices located far away, and can only be performed within a certain distance where Bluetooth communication is possible.

Q: As a specification for passkeys, I understand that WebAuthn Level 3 is still a draft, but I would like to know the current status difference between Level 2 and Level 3. Also, there are two types of specifications for Level 3, the w3.org and W3C.GitHubIO, but which one should we refer to for the implementation of this Hackathon?

A: Level 3 is still in the draft stage and contains many features that are not yet implemented in browsers. On the other hand, Level 2 is mostly implemented in browsers, so it is appropriate to refer to the Level 2 specification at the hackathon. The Level 3 specification is the latest draft, but there are still many parts that are not yet implemented.

Q: I think there are many cases of incorrect ID passwords, so what does the success rate of authentication using a passkey depend on?

A: The success rate of authentication with a passkey depends on the failure of biometric authentication, the state of the device (e.g. the passkey is not synchronized), user operation errors, etc. Although the success rate is higher than that of a password, it is not perfect.

Q: What is the exact definition of the word "Passkeys"?

A: There is no clear definition of the word "passkey" in the specifications. However, in general, a passkey refers to a secret key used for authentication. Since there is no strict definition, it is fine to understand it as the word "passkey".

Q: What specification defines terms such as Synced passkeys and Device-bound Passkeys?

A: The definitions of these terms are not in the specifications but are described in the FIDO Alliance FAQs. They are not defined in the official specifications.

Q: I would like to know the difference between a synced passkey and a non-synced passkey.

A: A sync passkey is a passkey that can be shared between multiple devices via the cloud, etc. A device-specific passkey exists only on a specific device and cannot be used on other devices. On Apple devices, all passkeys are sync passkeys, and on Android devices, you can choose sync/device-specific as an option.

Q: What kind of use cases are envisioned for attestation?

A: Attestation is used to verify whether a device is trustworthy. Since different device manufacturers have different signatures, it can be difficult to use for enterprise services. For general consumer services, it is appropriate to provide a passkey regardless of whether attestation is used or not.

4:57 Mercari's Passkey Case Study
24:23 Registering a passkey
50:28 Overview of passkey authentication flow
1:12:40 Break
1:25:22 Q&A Time

More Information

The above summary is too brief, so I asked Claude a few additional questions. Also, the fact that the code sample appears even though I only included the audio transcript seems to be due to the knowledge that Claude has. (So, I'm not sure if it's correct or not.)

Q. Please explain the server-side implementation for passkey registration.

Here is a detailed summary of the server-side implementation of passkey registration based on the explanation given at the conference:

  1. Generate the challenge:
    • The server generates a random value (challenge) for authentication.
    • This challenge is later used for challenge-response authentication.
  2. Preparing for registration options:
    • The server prepares the registration options, which include the following information:
      • Challenge
      • User information (user name, user ID, etc.)
      • Existing Credential ID (if already registered)
      • Relying Party (RP) information (name, RPID, etc.)
  3. Data Encoding:
    • The prepared information is typically URL-encoded in Base64 and sent to the client.
  4. Send to client:
    • It sends the encoded data to the client in JSON format.
  5. Receiving the response:
    • Receives the attestation response sent back by the client.
    • The response includes a JSON client data, an attestation object, and more.
  6. Decode and verify:
    • The received data is Base64 decoded.
    • Verify the decoded data.
  7. Verification process:
    • Challenge Match Check: Check if the challenge matches your saved one
    • Origin verification: Check if the origin is allowed by the RP
    • Extract Public Key: Extracts the public key from the attestation object.
    • Flag check: Check flags such as UV (User Verification), UP (User Presence), etc.
  8. Save your passkey:
    • If the validation is successful, we store the following information:
      • Public Key (required)
      • Credential ID (used for exclude credentials)
      • Algorithm (the cryptographic algorithm used for authentication)
      • Additional information for registration request (optional)
  9. Error handling:
    • If any problems occur during the validation process, an appropriate error message is generated and returned to the client.
  10. Security considerations:
    • Attestation verification: Performed to verify the reliability of a device or authenticator
    • Handling the User Verification (UV) flag: The process with or without the UV flag is determined according to the service policy.
  11. response:
    • A response is returned to the client indicating whether registration was successful or not.

Implementation notes:

  • Use a library: In many cases, a WebAuthn/FIDO2 library will be used to simplify the implementation.
  • Secure random number generation: A cryptographically secure random number generator is used for challenge generation.
  • RPID Settings: Set the RPID appropriately, which is important for phishing prevention.
  • Data persistence: Have a mechanism in place to securely store sensitive data such as public keys.

This implementation flow is a basic one, and the details may vary depending on the requirements of the specific service and the libraries used. It is important to implement according to the characteristics of each service while prioritizing security.

Q. Please explain the client-side implementation of passkey registration.

Here is a detailed summary of the client-side implementation of passkey registration based on the explanation given at the conference:

  1. Retrieving information from the server:
    • Access the server URL and obtain the information required for registration (optional).
    • The retrieved data is usually URL-encoded in Base64, so it must be decoded.
  2. Prepare the data:
    • Convert the decoded data into the appropriate format.
    • Key items include:
      • Challenge
      • RPID (Relying Party ID)
      • User information (name, displayName, etc.)
      • Public key generation parameters
  3. Call navigator.credentials.create() API:
    • Use the Web Authentication API to get started creating a passkey.
    • Pass the prepared data as an argument.
const publicKeyCredential = await navigator.credentials.create({
  publicKey: publicKeyCredentialCreationOptions
});
  1. User interaction:
    • The browser prompts the user to choose an authenticator.
    • Users verify their identity through biometric authentication or PIN entry.
  2. Generate a passkey:
    • The selected authenticator generates a passkey (a public/private key pair).
    • The private key is stored securely within the authenticator.
  3. Obtaining an attestation response:
    • The authenticator returns an attestation response that contains information about the generated passkey.
  4. Response handling:
    • Convert the returned attestation response into the appropriate format.
    • Key items include:
      • Client Data JSON
      • Attestation Objects
      • Public key
  5. Sending data to the server:
    • The processed data is sent to the server.
    • Data is typically Base64 encoded and sent in JSON format.
const response = await fetch('/register', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    id: base64url.encode(publicKeyCredential.rawId),
    rawId: base64url.encode(publicKeyCredential.rawId),
    type: publicKeyCredential.type,
    response: {
      clientDataJSON: base64url.encode(publicKeyCredential.response.clientDataJSON),
      attestationObject: base64url.encode(publicKeyCredential.response.attestationObject),
    },
  }),
});
  1. Error handling:
    • Gracefully handle any errors that may occur during the process.
    • The main errors include:
      • Cancellation by user
      • Unsupported Devices
      • time out
  2. UI Updates:
    • Provide proper feedback to users about the status of the registration process.

Implementation notes:

  • Browser compatibility: Not all browsers support the Web Authentication API, so it is important to have fallback options.
  • Security considerations: Minimize data processing on the client side and perform any significant validation on the server side.
  • User Experience: Provide proper guidance and error messages for a smooth registration process.
  • Platform-specific implementation: For mobile applications, you might need to use platform-specific APIs.

This implementation flow is a basic one, and the details may vary depending on the requirements of the specific application and the libraries used. It is important to implement it according to the characteristics of each application while balancing security and ease of use.

Q. Please explain the authentication steps using cross-device passkeys.

Here is a detailed explanation of the steps for authentication using cross-device passkeys, based on the explanations given at the conference:

  1. Authentication Starts:
    • A user attempts to log in on a device (e.g. a PC) for which they do not have the passkey.
  2. View authentication options:
    • The browser presents the user with authentication options.
    • Typically you'll be presented with the following options:
      • Use a passkey from another device
      • Use a security key
  3. Select Cross-Device Authentication:
    • The user selects "Use a passkey from another device."
  4. Display QR code:
    • A QR code will be displayed on the device (PC) you are trying to log in to.
    • This QR code contains the information required for authentication.
  5. Scan the QR code on your mobile device:
    • The user scans the QR code with a mobile device (such as a smartphone) that has the passkey.
    • For iOS: Scanning is possible with the standard camera app
    • For Android: Scan using the Google Lens app
  6. Establishing a Bluetooth connection:
    • After scanning the QR code, a Bluetooth connection will be established between the login terminal and your mobile device.
    • This connection is used to verify proximity between devices and provide additional security.
  7. Select a passkey:
    • The passkey for that account will be displayed on your mobile device.
    • If there are multiple passkeys, the user selects the appropriate one.
  8. User authentication:
    • User authentication (e.g. biometrics or PIN entry) occurs on the mobile device.
  9. Generate the signature:
    • If authentication is successful, a signature is generated on the mobile device using the passkey.
  10. Sending data:
    • The generated signature and other necessary data are sent to the login terminal (PC) via Bluetooth connection.
  11. Send to server:
    • The login terminal sends the received data to the server.
  12. Validation on the server:
    • The server verifies the data it receives and determines whether authentication is successful.
  13. Authentication complete:
    • If the verification is successful, authentication is completed on the login terminal (PC) and the user is logged in.

Notes and additional information:

  • Security: The combination of QR code and Bluetooth connectivity reduces the risk of remote unauthorized access by requiring physical proximity.
  • User experience: This method allows users to log in securely on devices where they don't have the passkey, but requires an extra step, such as scanning a QR code.
  • Device Restrictions: Currently, cross-device authentication can mainly be used on smartphones (Android or iOS).
  • Platform dependent: Specific implementation methods may vary slightly depending on the platform and browser used.
  • Bluetooth requirement: Bluetooth connection is required for cross-device authentication, preventing unauthorized access by scanning QR codes from a distance.

This cross-device authentication mechanism is an important feature that significantly improves the convenience of passkeys while maintaining security. However, it requires proper explanation to users and implementation.

footnote

  1. Graph available at 15:05

Leave a comment

This site uses Akismet to reduce spam.For details of how to process comment data, please click here.