[Security] Missing passwords on macOS and Linux

[Brave-Matt]

Description

There's a password loss issue effecting macOS and Linux.

@szilardszaloki:

Narrowed down to these 2 Beta versions:
Beta v1.68.106 (Chromium 126.0.6478.126)
Beta v1.68.107 (Chromium 127.0.6533.26)

In brave/brave-core@v1.68.106...v1.68.107 (while going from Chromium 126 to Chromium 127) we pulled in Remove undecryptable passwords from the login db (Chromium's bug) and at the same time removed a patch of ours (chromium_src/components/password_manager/core/browser/password_store/login_database.cc) that contained a change in the same exact function (LoginDatabase::StatementToForms()).

Combined effect of the two caused some passwords to be hidden in the password manager UI.

Follow-up to the original general data loss issue can be found here: #40375

[Brave-Matt]

These reports are still coming in:
https://community.brave.com/t/saved-passwords-missing-please-help/514428

[Brave-Matt]

More reports — not sure if I should keep adding threads here (I have not been doing so thus far):
https://community.brave.com/t/lost-everything-when-i-updated-browser/544719

[LaurenWags]

Brave | 1.69.88 Chromium: 127.0.6533.26 (Official Build) nightly (x86_64)
-- | --
Revision | d60303973dc3604d9d348b981322a8a04dcbb86d
OS | macOS Version 13.6.7 (Build 22G720)

Today I noticed that it appears as though my passwords are gone, but they can still be used. The short version is that brave://password-manager/passwords isn't showing my saved passwords on one profile, but the passwords still exist/are saved somewhere because I am offered them when I visit a site where I had previously saved them.

My general setup is that I have multiple profiles on my Nightly installation - but only 2 I really use. Of these two, both have a decent amount of usernames and passwords saved. One doesn't display any saved info on brave://password-manager/passwords, the other displays saved info on this page just fine. I have no idea how long this has been happening, I don't use the page itself much. So it's possible that this has been a problem for awhile. Other information: I don't have sync enabled for the profile with the problem, no errors are displayed in devtools, and don't have any extensions installed.

Below is an example of a site where I had previously saved username/password info to the profile, but then when I visit brave://password-manager/passwords the info isn't shown:

[bsclifton]

Quick note - @LaurenWags was able to fix the issue by launching from command line and appending --enable-features=SkipUndecryptablePasswords. She was on macOS - will let her share more info

[LaurenWags]

My general setup is covered under #33548 (comment) but can confirm, when using 1.70.18 if I launch with -–enable-features=SkipUndecryptablePasswords from the terminal I can see my passwords under brave://password-manager/passwords on macOS. If I don't use that when launching via the terminal, then then my passwords are not visible on that page.

Without extra flag	With extra flag

Note, my experience was limited to password loss - not tabs, bookmarks, etc.

Brave | 1.70.18 Chromium: 127.0.6533.73 (Official Build) nightly (x86_64)
-- | --
Revision | 433cfac052117c021a9f8d29e52afbdc91de7a00
OS | macOS Version 13.6.7 (Build 22G720)

[szilardszaloki]

@Brave-Matt @bsclifton @LaurenWags By default (on most platforms), the password manager hides all the passwords if there's at least one that's undecryptable. SkipUndecryptablePasswords just skips the passwords for which the encryption service fails and makes the decryptable ones available in the password manager, so passing --enable-features=SkipUndecryptablePasswords doesn't actually solve the problem, it just gives you a partial view — there must be at least one password that's corrupted. That's easily reproducible if, say, you save two passwords in the manager, and then manually corrupt one of them. Without SkipUndecryptablePasswords, none of the two shows up, but if you launch the browser with the feature flag, you get back the non-corrupted one.

@LaurenWags Can we jump on a call to find out which one of your passwords is corrupted? If we find the faulty one, we might be able to infer how it got corrupted exactly.

[mario-grgic]

I have encountered the same problem (macOS 14.6 and Brave Version 1.68.134 Chromium: 127.0.6533.88 (Official Build) (arm64)) where password manager would not display any passwords. I inspected the SQLite3 DB Login Data and the passwords were all there.

What I did to work around the problem is to launch Brave with --enable-features=SkipUndecryptablePasswords which allowed me to export the passwords as CSV.

I then made backup of the Login Data database, deleted it, launched Brave normally and imported the CSV that I exported above. I now have passwords in the password manager.

Consequently, I now have DB with undecryptable passwords and working one. The original DB with undecryptable passwords has 155 passwords, the fixed one has 113. A lot of rows in the "corrupted" DB are duplicates with only 3 unique rows.

Not sure what to try next and how would I find undecryptable passwords in the "corrupted" DB?

[szilardszaloki]

Thanks for reporting the above @mario-grgic.
Would you be able to:

1. go to the Keychain Access app,
2. search for Brave Safe Storage, and
3. check when your entry was last modified?

[mario-grgic]

@szilardszaloki Date Modified: Nov 22, 2023 at 4:35:56 PM (this matches the time this new machine was setup and Brave installed).

[szilardszaloki]

@mario-grgic That's very helpful, thanks!

Narrowing down your passwords to only the faulty ones is not impossible, but a bit elaborate.

Basically, after doing a backup (!) of your original Login Data database, try to identify a range of rows in the logins table for which your passwords show in brave://password-manager/passwords (without passing --enable-features=SkipUndecryptablePasswords) — in other words, keep the range of your choice and remove everything else from logins. Now, if you can see your passwords showing in the Password Manager, it means that all your faulty passwords are among the rows you removed from the logins table, otherwise you'll have to pick another range and redo this step — the algorithm itself is linear in the number of passwords, but the wider the range of rows you start out with is, the less time it'll take to complete the rest of the steps.

Now you want to try to reduce the set of rows that you remove from logins and extend the one that you keep, row by row. Whenever you see that your passwords disappeared from brave://password-manager/passwords, it means that you added back a faulty password. Take a note of it and make sure you exclude it from further processing. If you keep on doing this until the set you remove from logins becomes empty, the passwords you've taken note of will be the ones the Encryption service in Chrome has trouble decrypting.

[mario-grgic]

I have a hypothesis on how I may have gotten into this state. When I setup the new computer, I used rsync to copy my Brave data in ~/Library/Application\ Support/BraveSoftware to the new computer. When launching the Browser on the new computer I noticed passwords and possibly (if memory serves me right) bookmarks were missing, so I exported both on the old computer and imported on the new one.

This may explain the duplicate saved passwords I see and would also explain two different passwords encrypted with different keychains.

Come to think of it, users that use Timemachine backups to restore their profile on different computers would run into similar issue and this is probably a fairly common use case for macOS users.

@szilardszaloki I have found a few URLs for which I have two different hex encoded passwords. One is decryptable on new machine, the other is not.

[szilardszaloki]

Migrating profiles that way would definitely be problematic, since the Brave Safe Storage password on the new machine wouldn't match the one on the old one. But then you've already experienced this issue before when launching Brave on the new machine for the first time, correct? When you exported/imported your passwords, did you remove Login Data on the new machine first, and just then did the import?

Also, I suspect not, but asking anyway — do you still have the old machine by any chance?

[mario-grgic]

@szilardszaloki I definitely did not remove Login Data DB on the new machine before importing data. And yes, I did experience the problem where passwords were not shown. I didn't investigate much and just imported passwords from the exported CSV on top of old Login Data.

However, not sure what caused the recent regression in Brave to surface this issue again. I am in good state now, however, I'm sure average user will have a lot more trouble with this.

And to answer the question, unfortunately, I got rid of the old machine a few months back.

[szilardszaloki]

The curious thing is that importing the passwords from the exported CSV on top of the corrupted Login Data shouldn't have fixed anything for you back then. Temporarily it does seem that the issue goes away when doing the import (i.e. you can see your newly imported passwords appearing in brave://password-manager/passwords), but only until the next launch, as logins in Login Data is not being overwritten — passwords are appended.

[LaurenWags]

Requires 1.68.139 or higher for testing 👍🏻

[LaurenWags]

Verified with

Brave | 1.68.140 Chromium: 127.0.6533.100 (Official Build) (64-bit)
-- | --
Revision | 612f5cee6491be373e8133bcda3f56522fbe621e
OS | Linux

Clean Profile - PASSED

1. open the browser using 1.68.140
2. go to brave://password-manager/passwords
3. add two passwords:
   1. password
      1. Site: aaaaa.com
      2. Username: aaaaa
      3. Password: aaaaa
   2. password
      1. Site: bbbbb.com
      2. Username: bbbbb
      3. Password: bbbbb

4. close the browser
5. open ~/Library/Application Support/BraveSoftware/Brave-Browser/Default/Login Data in DB Browser for SQLite
6. go to Execute SQL
7. paste

   UPDATE logins SET password_value = x'7631301f2bb0cc71024cedf754d0992d32' WHERE username_value = 'aaaaa'
   

   hit F5, then save (e.g. Cmd + S)

8. close DB Browser for SQLite
9. open the browser
10. make sure the password for bbbbb.com is still showing

Upgrade profile - PASSED

pre-req: disable internet before testing so griffin seed isn't pulled as there is currently a griffin study to enable this feature on Release channel

1. using 1.68.137 open the browser
2. go to brave://password-manager/passwords
3. add two passwords:
   1. password
      1. Site: aaaaa.com
      2. Username: aaaaa
      3. Password: aaaaa
   2. password
      1. Site: bbbbb.com
      2. Username: bbbbb
      3. Password: bbbbb

4. close the browser
5. open ~/Library/Application Support/BraveSoftware/Brave-Browser/Default/Login Data in DB Browser for SQLite
6. go to Execute SQL
7. paste

   UPDATE logins SET password_value = x'7631301f2bb0cc71024cedf754d0992d32' WHERE username_value = 'aaaaa'
   

   hit F5, then save (e.g. Cmd + S)

8. close DB Browser for SQLite
9. open the browser
10. confirm that no passwords are displayed on the password manager

11. Update to 1.68.140
12. make sure the password for bbbbb.com now displays on the password manager

[LaurenWags]

Verified with

Brave | 1.68.141 Chromium: 127.0.6533.120 (Official Build) (x86_64)
-- | --
Revision | b3f23500b575d50584510ea1814ef440d30741a8
OS | macOS Version 13.6.9 (Build 22G830)

Clean Profile - PASSED

1. open the browser using 1.68.141
2. go to brave://password-manager/passwords
3. add two passwords:
   1. password
      1. Site: aaaaa.com
      2. Username: aaaaa
      3. Password: aaaaa
   2. password
      1. Site: bbbbb.com
      2. Username: bbbbb
      3. Password: bbbbb

4. close the browser
5. open ~/Library/Application Support/BraveSoftware/Brave-Browser/Default/Login Data in DB Browser for SQLite
6. go to Execute SQL
7. paste

   UPDATE logins SET password_value = x'7631301f2bb0cc71024cedf754d0992d32' WHERE username_value = 'aaaaa'
   

   hit F5, then save (e.g. Cmd + S)

8. close DB Browser for SQLite
9. open the browser
10. make sure the password for bbbbb.com is still showing

Upgrade profile - PASSED

pre-req: disable internet before testing so griffin seed isn't pulled as there is currently a griffin study to enable this feature on Release channel

1. using 1.68.137 open the browser
2. go to brave://password-manager/passwords
3. add two passwords:
   1. password
      1. Site: aaaaa.com
      2. Username: aaaaa
      3. Password: aaaaa
   2. password
      1. Site: bbbbb.com
      2. Username: bbbbb
      3. Password: bbbbb

4. close the browser
5. open ~/Library/Application Support/BraveSoftware/Brave-Browser/Default/Login Data in DB Browser for SQLite
6. go to Execute SQL
7. paste

   UPDATE logins SET password_value = x'7631301f2bb0cc71024cedf754d0992d32' WHERE username_value = 'aaaaa'
   

   hit F5, then save (e.g. Cmd + S)

8. close DB Browser for SQLite
9. open the browser
10. confirm that no passwords are displayed on the password manager

11. Update to 1.68.141
12. make sure the password for bbbbb.com now displays on the password manager

[mario-grgic]

I can confirm that the issue is fixed. Tested with Brave 1.68.141 Chromium: 127.0.6533.120 (Official Build) (arm64) and my original Login Data DB. All passwords are showing again.