Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed Saved Passwords section in settings is empty #5656

Merged
merged 1 commit into from
Jun 3, 2020

Conversation

simonhong
Copy link
Member

@simonhong simonhong commented May 26, 2020

Some users reported that Saved Passwords sections is empty but passwords are autofilled
to website's password form on linux and macOS.

I think this can happen if user insert/update new password entries after login db encryption
is corrupted.
However, currently user can't anything even if current login db has decryptable entries.

The reason is LoginDatabase::StatementToForms() gives empty password entry when any entry in
login db has decryption failure on linux and macOS.

To fix this, ENCRYPTION_RESULT_ITEM_FAILURE is used for individual decryption failure
instead of ENCRYPTION_RESULT_SERVICE_FAILURE.

If ENCRYPTION_RESULT_SERVICE_FAILURE is returned, LoginDatabase::StatementToForms() assumes
all other entries will have decrypt failure. However, db could have decryptable entries
even if current entry is failed to decrypt.

Resolves brave/brave-browser#3196

Submitter Checklist:

Test Plan:

  1. Save some passwords by using Chrome and copy chrome's Login Data in user's profile folder to Brave's folder
  2. Launch Brave and checks Saved Passwords section(brave://settings/passwords) is empty
  3. Update some passwords by revisiting some websites
  4. Check Saved Passwords section displays newly added passwords

Reviewer Checklist:

  • New files have MPL-2.0 license header.
  • Request a security/privacy review as needed.
  • Adequate test coverage exists to prevent regressions
  • Verify test plan is specified in PR before merging to source

After-merge Checklist:

  • The associated issue milestone is set to the smallest version that the
    changes has landed on.
  • All relevant documentation has been updated.

@simonhong
Copy link
Member Author

Filed issue to crbug.com - https://bugs.chromium.org/p/chromium/issues/detail?id=1086348

@simonhong simonhong force-pushed the fix_password_not_shown_in_settings branch from 02809ee to 65dcaef Compare May 27, 2020 05:47
return ENCRYPTION_RESULT_SUCCESS;

- return OSCrypt::IsEncryptionAvailable() && IsUsingCleanupMechanism()
+ return OSCrypt::IsEncryptionAvailable() /* && IsUsingCleanupMechanism() */
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why aren't we using kDeleteCorruptedPasswords to fix this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok - Using kDeleteCorruptedPasswords could work on macOS.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bridiver Fixed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I think using kDeleteCorruptedPasswords by default seems dangerous.
Brave will clear all passwords if decryption is failed temporarily.
How about using my initial way?

@simonhong simonhong force-pushed the fix_password_not_shown_in_settings branch 2 times, most recently from f707dcc to c957228 Compare June 2, 2020 02:19
EncryptionResult result = InitPasswordFormFromStatement(
*statement, /*decrypt_and_fill_password_value=*/true, &primary_key,
new_form.get());
+ if (result == ENCRYPTION_RESULT_SERVICE_FAILURE) result = ENCRYPTION_RESULT_ITEM_FAILURE;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please convert to standard patch format BRAVE_STATEMENT_TO_FORMS

Some users reported that Saved Passwords sections is empty but passwords are autofilled
to website's password form on linux and macOS.

I think this can happen if user insert/update new password entries after login db encryption
is corrupted.
However, currently user can't anything even if current login db has decryptable entries.

The reason is LoginDatabase::StatementToForms() gives empty password entry when any entry in
login db has decryption failure on linux and macOS.

To fix this, ENCRYPTION_RESULT_ITEM_FAILURE is use for individual decryption failure
instead of ENCRYPTION_RESULT_SERVICE_FAILURE.

If ENCRYPTION_RESULT_SERVICE_FAILURE is returned, LoginDatabase::StatementToForms() assumes
all other entries will have decrypt failure. However, db could have decryptable entries
even if current entry is failed to decrypt.
@simonhong simonhong force-pushed the fix_password_not_shown_in_settings branch from c957228 to ba2de6f Compare June 2, 2020 22:58
@simonhong simonhong merged commit 338150a into master Jun 3, 2020
@simonhong simonhong deleted the fix_password_not_shown_in_settings branch June 3, 2020 01:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Desktop] Saved passwords are not shown in brave://settings/passwords
2 participants