Credential Management API Password save is not persisted |
|||||
Issue description
Chrome Version: 64.0.3282.186, 65.0.3325.181, 66.0.3359.181
OS: Linux
What steps will reproduce the problem?
(1) Store a password credential
(2) Wait for the user to click save on the password dialog
(3) Get the password credential
const credential = await navigator.credentials.create({
password: {
id: 'myid',
name: 'myname',
password: 'mypassword',
},
});
await navigator.credentials.store(credential);
// wait for user to click save
const savedCredential = await navigator.credentials.get({password: true});
What is the expected result?
savedCredential gets a value
What happens instead?
savedCredential is empty
I've had a number of users report this kind of issue. They all have password management enabled and they all see the password save dialog and click save; however, even after that the password cannot be retrieved. The password that was "saved" does not appear in chrome://settings/passwords either. In every case if the user restarted chrome things started working.
,
May 24 2018
A user actually also reported a case on Mac. I don't know if they saw a keyring unlock prompt, but I don't usually see one when I start chrome or use the credential api on linux. One person mentioned did mention that chrome://settings/passwords was empty. Are there any logs or other information that would be useful to collect next time someone hits this? I think everyone I know of who has hit is has worked around by restarting chrome, but someone seems to report an issue every couple days so there will probably be another chance to collect logs soon if needed.
,
May 25 2018
,
May 25 2018
Let's not mix different bugs. Mac is Issue 171925. The questions to ask are - Does the Keychain unlock automatically on startup? - Was there any prompt to unlock the Keychain? - Were there Mac updates, restarts before the issue happened. Regarding Linux: - What is the status of the Keyring? Unlocked automatically on restart? ('seahorse' is the name of the app to check it). - when it happens again it's useful to try to save the credential on a a testing page https://rsolomakhin.github.io/autofill/ (there is no API, just a form submission). Did the credential appear in the Keyring? Are other existing credentials displayed on chrome://settings/passwords? What is the status of passwords on chrome://sync-internals/?
,
May 25 2018
> What is the status of the Keyring? Unlocked automatically on restart? seahorse didn't prompt to unlock or anything so yes it automatically unlocks? > https://rsolomakhin.github.io/autofill/ Saw password save popup on submit; however the passwords were not automatically filled upon re-navigating back to the form. > Did the credential appear in the Keyring? No > Are other existing credentials displayed on chrome://settings/passwords? None auto sign-in and offer to save passwords are checked > What is the status of passwords on chrome://sync-internals/? Error: MergeDataAndStartSyncing@../../components/password_manager/core/browser/password_syncable_service.cc:149, datatype error was encountered: Failed to get passwords from store. status is: Not Running Group Type: Group Passive Any other info that would be useful to collect
,
May 28 2018
Christos, please lead the investigation.
,
May 28 2018
> seahorse didn't prompt to unlock or anything so yes it automatically unlocks? I still think it might be a problem with keyring. Please confirm that they were able to open a keyring and view a password. There should be at least one entry, named "Chrome safe storage". Keep in mind that Seahorse prompts to unlock when you try to read the credentials, not when you simply start it. Please confirm that you are able to find and view this entry without an unlock prompt. Also, what is the name of the keyring? Is it "Login"? >Any other info that would be useful to collect Is it possible to get logs from a user? Specifically, it would be useful if they recreated the problem on https://rsolomakhin.github.io/autofill/ when running Chrome as such: google-chrome --enable-logging --vmodule=*key_storage*,*password_store*=1 The logs are typically in ~/.config/google-chrome/chrome_debug.log If it's not there, they can find the location of their Chrome data folder in chrome://version.
,
May 28 2018
Actually, if we can get logs, lets expand the logging a bit google-chrome --enable-logging --vmodule=*key_storage*,*password_store*,*native_backend*=1 That would also give us what error keyring returns, if that's where the problem occurs. Thanks!
,
May 28 2018
See Chrome Mac forum thread https://productforums.google.com/forum/#!topic/chrome/nEz4AGsl0no I've tagged this as a 'main' thread on ~15 threads, and put short summaries in the main thread. Sorry I was only looking for Mac reports. The first pattern I saw was new Macs either new hardware or new Chrome installs. I think this may be a red-herring. Next pattern is regression on 66.0.3359.181 - Some users reporting 'since last update'. There were a couple of cases linked to Mac security update or keychain repair. It's not just new passwords. Chrome Settings...>Manage Passwords is empty but passwords.google.com is OK. Use this forum mac passwd search to find cases https://productforums.google.com/forum/#!topicsearchin/chrome/password$20category$3A(mac)%7Csort:date or mac autofill - not as specific, but more cases.. https://productforums.google.com/forum/#!topicsearchin/chrome/autofill$20category$3A(mac)%7Csort:date I'm posting the log request to the 'main' thread https://productforums.google.com/forum/#!topic/chrome/nEz4AGsl0no
,
May 29 2018
Issue 845680 attributes password autofill loss to sync failure. An attached sync-internals dump and screenshot shows a password sync error. Can I have a few lines of instructions for the AutoFill Smoke Test that I can pass on to users? Looks like they should complete a few sections and submit with logging enabled? Re: overlap with Issue 171925 -This is a persistent user failure. Broken users stay broken (until..?) -only 3-4 of the 20 user reports I scanned mentioned keychain maintenance. I'm seeing new reports almost hourly, but very few repeat comments or followup (5 / 20). It's possible that sync recovers eventually.
,
May 29 2018
vasi@ - When there's been a Mac or keychain update recently, is there a cleanup to fix Chrome access with the new keychain key? Anything better than: change the Keychain settings so that it unlocks automatically (on OS user sign in)?
,
May 29 2018
,
May 29 2018
See also Mac sync issue 845680 for recent, possibly M66..181 regression issues and (my) master forum thread https://productforums.google.com/forum/#!topic/chrome/nEz4AGsl0no The incidence of password missing reports seems to have increased since the Mac 66.0.3359.181 release, but that's largely subjective. Issue 171925 is historic, dating back several years. It's hard to identify the latest trends there. Issue 845680 seems to reflect the recent failure mode(s) more clearly. Re: keychain: How can a user determine if their (which?) keychain is open for Chrome access? If healthy, can they see the (presence of) Chrome site passwords in the keychain?
,
May 30 2018
I commented on Issue 845680. The passwords are not stored in the Keychain, only the encryption key.
,
May 30 2018
vasi@ #15: OK Re: issue 171925: See my cmt there: You/vasi meant? Passwords saved in keychain - Chrome Safe Storage and needs login keychain (opened) and (original) key to decrypt?
,
Aug 2
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by vasi...@chromium.org
, May 24 2018Labels: Needs-Feedback OS-Linux