*INTRODUCTION* Passkeys on Android are stored in Google Password Manager by default. The user cannot make their own backups of them.
Note: although the user can export a CSV file with both passkeys and passwords, the lines representing passkeys will not contain any secrets, rendering them useless. Also note that Google Passkey Manager appears to primarily be a CLOUD-based password manager (with copies of passwords and passkeys usually cached on devices). *PROBLEM* The user may have chosen to configure a "sync passphrase" in Chrome. Instructions on what to do, in case the user wishes to change or remove their sync passphrase, can be found in [1] under "Reset your passphrase". Effectively the user is sent to [2] and should press the button "Clear Data" at the bottom of that page. Until mid June 2023, the text near that button used to read (emphasis in CAPS added by me): "This will clear your Chrome data from your Google Account. THIS WON'T CLEAR ANY DATA FROM YOUR DEVICES." However, tapping the "Clear Data" button would unrecoverably DELETE ALL YOUR PASSKEYS (not your passwords). *ISSUE REPORTED TO GOOGLE* I reported this "passkeys gone" problem to Google as a security issue on June 11, 2023. Please see the Timeline below for details. *"FIX"* The issue was "fixed" around June 15, 2023, apparently by changing the text at the bottom of [2] into (emphasis in CAPS added by me): "This will clear your Chrome data that has been saved in your Google Account. THIS MIGHT CLEAR SOME DATA FROM YOUR DEVICES." However, tapping the "Clear Data" button will still DELETE ALL OF YOUR PASSKEYS without any other warnings. In my opinion this is unacceptable, as is the handling of my bug report. Therefore I have not yet reported the issues mentioned below to Google nor to the Chromium team. *POTENTIAL SYNC ISSUES* Apparently Google decided to use a DEVICE based encryption key (instead of a Google ACCOUNT based key) to encrypt the passkey's private keys. The idea is that, if you start using an second Android device, the encryption key from the first device is transferred to your second device. Note that this requires you to enter your Google cloud password PLUS the screen unlock code of your first device on your second device. However, transfer of the encryption key will fail if the second device ALREADY HAS an encryption key. Note: I actually ran into this condition accidentally during tests. Although this may not be a typical situation, it is possible to reproduce (which I will not (yet) describe). Consequently, if you you brick or loose your old Android device, and somehow you managed to already have a DIFFERENT encryption key on your new Android device, passkeys and passwords will sync from the cloud, but the synced passkeys will be UNUSABLE on your new device. Tip: whatever you do on a new replacement device: don't start by creating a passkey as a test! Wait until your old passkeys have synchronized to your new device and you've confirmed that they work, before you add any new passkeys. *BUG IN PASSWORDS.GOOGLE.COM* Editing a passkey's (user) name in [3] renders all passkeys for the domain unusable, with the following error message when attempting to use them: "No Passkeys Available There aren't any passkeys for [domain] on this device" That particular passkey will be unusable forever. However, any other passkeys for the same domain become usable again after you delete the -now corrupt and unusable- passkey. *OTHER ISSUES* During my tests I found a lot of other issues (mostly minor compared to those mentioned above). Such as the following worrisome messages I repeatedly saw: "An unknown error occurred while talking to the credential manager." "For security, you can no longer access your encrypted data on this device." Also, in Chrome settings, after enabling sync, tapping on "Password Manager" would usually open Google Password Manager (implemented as a part of Google Play Services), but sometimes the Chrome built-in password manager instead. I may reveal other issues at a later stage. *CONCLUSION* In my opinion the reliability of Android's passkey implementation insufficient (immature, not production ready). There is no way for the user to back up their passkey secrets themselves, while cloud storage of passkeys can obviously not be relied upon (Google owns your passkeys, not you). The partial integration of Google Password Manager with Chrome's builtin password manager complicates things - in particular when combined with a "sync passphrase" and/or "on device encryption". The apparent confusion which party (Google or the Chromium team) is responsible for fixing bugs in Google Password Manager seems amateuristic annd chaotic. Account lockout is a serious risk. If fallbacks to passwords or recovery codes remains a necessity because of easily lost passkeys, the advantage of "phishing resistance" is mostly moot. *DISCLOSURE TIMELINE* (format: yyyy-mm-dd) 2023-06-06 I published a Dutch article "Passkeys voor leken" (Passkeys for beginners) [4]. 2023-06-08 After enabling encryption (using a sync passphrase) for all synced data, and then following Google's instructions [1] on how to change that passphrase, I noticed that all passkeys on my Google Pixel 6 Pro Android phone had disappeared. I wrote about this in [5], but initially thought that I made a mistake myself. After thid incident I started to further investigate this issue, which appeared to reproduce. 2023-06-11 I uploaded a vulnerability report to Google titled "Passkeys gone from device after clearing Chrome data from Google Account" [6]. 2023-06-12 Google acknowledges receiving my report. 2023-06-14 Google forwards my report to the Chromium team [7] and sets the status of the Google issue to "Won't Fix (Infeasible)". 2023-06-14 Im am notified that my vulnerability report was registered by the Chromium team. In [7] I see that the issue was assigned to a specific person (the "assignee" from now on). 2023-06-15 On the bug tracking website [7] I uploaded a zip-file with screenshots to further clarify things. 2023-06-15 The assignee wrote in [7]: "This is as expected, but you're right that we should clarify that on the page and that it's unexpected that Android's implementation of Sync differs r.e. the clearing of data from devices." 2023-06-15 The assignee adds a comment: "> it's unexpected that Android's implementation of Sync differs r.e. the clearing of data from devices. (Sorry, that was poorly worded. It's potentially _surprising_ that Android differs given the wording.)" At that time I did not understand what the assignee meant. Later I discovered by accident that the text at the bottom of [2] had been changed, and the assignee was apparently referring to that text. 2023-08-10 After 60 days since my initial report, I addded a comment in [7] that I am able to reproduce the vulnerability using the latest (August) Android update. I added: "I don't know whether this is a Chromium or an Android issue, but losing passkeys is unacceptible. What gives?" 2023-09-10 (after 90 days) On [6] I reported that I had not heard back from the Chromium team since June 15 and that I do not understand what they wrote that day, and that there was no response to my August 8 comment. 2023-09-11 My latest comment in [6] is acknowledged by Google and under review. 2023-09-15 Google states that they won't do anything as this vulnerability is tracked by [7]. 2024-02-07 No updates on [6] and [7]. Publication. *REFERENCES* [1] https://support.google.com/chrome/answer/165139 [2] https://chrome.google.com/sync [3] https://passwords.google.com/ [4] https://security.nl/posting/798699/Passkeys+voor+leken [5] https://security.nl/posting/798932 [6] https://issuetracker.google.com/issues/286730198 [7] https://bugs.chromium.org/p/chromium/issues/detail?id=1454857 _______________________________________________ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: https://seclists.org/fulldisclosure/
