Passkey Lost Device

[Marquez Feliciano]

Thusmany people are skeptical of passkeys, the new protocol from the FIDO Alliance that purports to drastically improve the safety, security, and user experience of logging in to websites and mobile applications.

Passkeys have been officially announced by Apple and put into developer builds for Chrome and Android by Google. Microsoft is preparing its version as well. The reason that these three companies are critical to adoption is that they represent the vast majority of devices, computers, browsers, and operating systems. If these three all agree on something, then there is probably something to it.

Since both Apple and Google have announced support for passkeys, there have been many articles describing passkeys, how they work, and how the tech giants will support them. Many have been informative, but a few have been, well, confusing.

One of the benefits of passkeys is that they are promised to be shared across devices within the given ecosystem of each of the big tech companies. This means that if you lose your phone, your passkeys are securely stored (via end-to-end encryption) in the cloud. They can be restored when you get a new phone.

It depends on the password manager implementation, whether a credential providerallows for a passkey creation and authentication without a user knowledge factorchallenge. Providers can prompt users to set up a PIN or biometric screen lockbefore creating a passkey.

A passkey registered on Android, for example, can be used to sign-in on otherplatforms by connecting the Androidphone with another device.To establish a connection between the two devices users need to open the sitethey are trying to sign in to on a device that doesn't have a passkeyregistered, scan a QR code, and then confirm the sign-in on the device they hadcreated the passkey on (in this case, the Android device). The passkey neverleaves the Android device, so typically apps will suggest creating a new passkeyon the other device to facilitate the sign-in the next time. This flow will workin a similar way for other platforms as well.

Passkeys are saved to the credential provider defined by the platform. Someplatforms, like Android, allow users to choose the provider of their choice (asystem or third-party password manager) starting in Android 14, whichmay be able to synchronize passkeys across different platforms. Support formoving passkeys directly from one platform provider to another is not availableat this time.

Android is opening up the platform (starting in Android 14) to allow users toselect which credential provider they want to use (such as a third-partypassword manager). That will enable use cases like synchronizing passkeysbetween different ecosystems (depending on how open other platforms are).

If the passkey is created in Chrome on other platforms (Mac, iOS, Windows),then no. Check out the supported environmentsfor more information. Meanwhile, users can use the phonethey created the passkey on to sign in.

It depends on the device platform and how they run the user verification. In thecase of Google Password Manager, the passkeys arenot tied to any specific authentication methods and can be used with any screenlock factor available (biometric, PIN, or pattern).

When using passkeys, the device public key extensionwhich is under development is a second, device-bound key that won't be syncedand that can be used for risk analysis. However, this is not supported by anycredential providers yet.

If the passkeys were saved to Google PasswordManager, then all the user needs to do is sign inon the new device with the same Google account and verify themselves withtheir previous device's screen lock (PIN, pattern or passcode). The previousdevice is not required for the user to login to other devices.

If the passkeys were saved to a different credential provider, it will dependon the sign-in flows on new devices of that credential provider. Mostcredential providers synchronize the credentials to the cloud and offer waysto users to access them on new devices after authenticating themselves.

Identity federation is great forsigning up to a service, as it returns the user's basic profile information suchas name, and verified email address, which help bootstrap new accounts. Passkeysare great for streamlining users'reauthentication.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

As a followup to my piece on passkeys, reader Andrew pointed me to a blog post by Terence Eden, which contains a bit of a thought experiment on what happens if you have a catastrophic accident (say, a house fire) and lose access to all your devices:

In order to recover my digital life, I need to be able to log in to things. This means I need to know my usernames (easy) and my passwords (hard). All my passwords are stored in a Password Manager. I can remember the password to that. But logging in to the manager also requires a 2FA code. Which is generated by my phone.

To recover a keychain, a user must authenticate with their iCloud account and password and respond to an SMS sent to their registered phone number. After they authenticate and respond, the user must enter their device passcode. iOS, iPadOS, and macOS allow only 10 attempts to authenticate. After several failed attempts, the record is locked and the user must call Apple Support to be granted more attempts. After the tenth failed attempt, the escrow record is destroyed.

That said, this is also a possible vector for social engineering, so extra levels of security are probably a good thing here. Requiring iCloud password, SMS code, and device passcode altogether seems like a reasonable set of steps to take before giving access back to a keychain.

When adding new devices, the passkey is used as the first step here - all good. Then, an additional confirmation is needed on one of the connected devices - ok, I guess. It's similar to the "password + secret key" flow, where the passkey replaces the password, and the confirmation on another trusted device replaces the secret key.

Of course, devices can get lost, so what happens then: with "password + secret key", the secret key is part of the emergency kit, and the password can (but doesn't have to) be written down as well depending on the user preference. That means setting up a new device requires only the emergency kit and, optionally, knowledge of the password (if the user didn't write it down on the emergency kit) - no need to have any of the previously connected devices.

Well, with passkeys, there's now a new "recovery code", except it doesn't actually replace a lost device; it replaces a lost passkey. In this case, the passkey isn't required at all, but instead the user needs access to their email. This makes little sense to me for the following reasons:

I understand HW keys are not for everyone, so losing the passkey is surely a possibility worth considering, but it seems that the current recovery process won't work for many users anyway because of the second point, while it also completely neglects the other scenario, where you do have the passkey but no longer have any connected device and email access.

Yes but that's the thing - passkeys are easy to store in a safe place on a HW key. Email access can easily be lost together with 1P access. There should be a recovery flow based on recovery code + passkey, not recovery code + email.

Thank you for the feedback on our public beta for passkey unlock! The team continues to iterate and improve this exciting new feature and I appreciate you taking the time to let us know your thoughts.

You're correct that the passkey is used as a "first step" when it comes to authenticating to the 1Password server, the actual keys used to decrypt your data are transmitted from an existing trusted device to the device that you're signing in on using end-to-end encryption.

The recovery code allows you to perform a recovery of your data but, as you mentioned, it alone isn't enough to fully restore access. This is by design since we want to make sure that a stolen recovery code can't lead to account takeovers. This is why an extra step, using a confirmation code sent to your email address, is required when using a recovery code.

I understand that the email address confirmation step may not work for everyone and I've passed along your feedback to the team. Passkey unlock is still in beta which means that a lot can change before the final release, your feedback that you'd like to see other recovery options helps us to improve passkey unlock for everyone. ?

As part of our operations, we have nodes in Hong Kong (hktt4, 7nodes from origingames), and we are in the process of applying for nodes in South Korea (estimated in 10 nodes machines). However, the inability to access the NNS system is causing significant disruption. I am reaching out to inquire if there is a solution or any assistance you can provide to help me regain access.

I can provide proof of ownership through various means, including the Internet Identity associated with the account, the hardware wallet used for interactions with NNS, the node_operator_private_key.pem file, and evidence of ownership for the nodes currently operational online.

Method of Internet Identity Registration: We utilized Chrome on Mac for the initial registration of Internet Identity. However, after an auto-update, all automatically generated passkeys were lost. Unfortunately, Chrome did not have any accounts logged in at that moment, resulting in the loss of the passkey.

Missed or Overlooked Details: In our efforts, we have diligently reviewed all available data and sought assistance from Google. However, despite our best efforts, we have not been able to identify any overlooked or missed details.

Proof of Identity for OriginGame: We can provide evidence of the NNS-connected cold wallet, NNS system-related ID, the cold wallet used for interactions with the NNS system, node_operator_private_key.pem documents, and evidence of ownership for all currently operational node machines under the name of OriginGame.

3a8082e126