Where are my browser passwords stored?

Question

When we prompt our browser to save credentials once we log into a web application, they store our corresponding username and password. I know to recover these things from my browser. But I want to know to which directory in Ubuntu these passwords are stored?

Answer 1

Chromium and Chrome

Store passwords in three ways:

1. GNOME Keyring
2. KWallet 4
3. plain text

Chromium chooses which store to use automatically, based on your desktop environment.

Passwords stored in GNOME Keyring or KWallet are encrypted on disk, and access to them is controlled by dedicated daemon software. Passwords stored in plain text are not encrypted. Because of this, when either GNOME Keyring or KWallet is in use, any unencrypted passwords that have been stored previously are automatically moved into the encrypted store.

Source for Chromium.

The manual page for google chrome (man google-chrome) shows:

--password-store=<basic|gnome|kwallet>
          Set the password store to use.  The default is to  automatically
          detect  based  on  the  desktop  environment.  basic selects the
          built in,  unencrypted  password  store.   gnome  selects  Gnome
          keyring.  kwallet selects (KDE) KWallet.  (Note that KWallet may
          not work reliably outside KDE.)

Chrome uses the same method as Chromium. And you can use above setting to switch to plain text passwords (not recommended of course).

Chrome (older versions)

Passwords are stored in ~/.config/google-chrome/Default/Login\ Data and that is a sqlite database file (that file is encrypyed).

This login database file is in SQLite format which is lighter version of popular SQL database. In addition to login credentials it also stores other information such as auto complete entries, IE7 Logins, search keywords etc. The 'logins' table is where all the login or sign-on secrets are stored by Chrome. This table contains following interesting fields

Origin_URL - Base URL of the website
Action_URL - Login URL of the website
Username_element - Name of the username field in the website
Username_value - Actual username
Password_element - Name of the password field in the website
Password_value - Encrypted password
Date_created - Date when this entry is stored
Blacklisted_by_user - Set to 1 or 0 based on if website is blacklisted or not.

Except the password field all other fields are entered in clear text. The password for all stored websites is encrypted using Triple DES algorithm seeded with logged on user's password. That means login secrets cannot be decrypted across the user or system boundaries unless under certain conditions.

Source for Microsoft Windows.

Firefox

See ~/.mozilla/firefox/<profilename>

Your passwords are stored in the key4.db and logins.json files.

Source.

Answer 2

Ubuntu 20.10 Chromium stores passwords at ~/snap/chromium/common/chromium/Default/Login Data

The following two thing have changed since the answer Where are my browser passwords stored? was written:

• as pointed out by Ruggero Turra, they apparently went back from the GNOME keyring to the custom SQLite database as announced at: https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md#Does-the-Password-Manager-store-my-passwords-encrypted-on-disk
• Chromium is now a snap by default, so the default profile is now at ~/snap/chromium/common/chromium/Default/ rather than the old ~/.config/chromium

One easy way to test this out is to create a new login on some website that you had not signed up for, e.g. I chose https://www.onlylads.com/

Then, after Chromium asks you to save the password and you agree, quit Chromium to unlock the database, and do:

sqlite3 ~/snap/chromium/common/chromium/Default/Login\ Data 'SELECT * FROM logins' |
  grep -a onlylads

and this now contains an entry of type:

https://www.onlylads.com/join/register/|https://www.onlylads.com/join/register/|new_email|<your-email>|new_password|<encrypted-password-blob>|6KӜYTP||https://www.onlylads.com/|13257819658687161|0|0|0|0||0||||0|0|@|543|13257819641704329|

which confirms that it stores an encrypted password, with other fields being plaintext.

We can also get the corresponding schema with:

sqlite3 ~/snap/chromium/common/chromium/Default/Login\ Data .schema

which gives:

CREATE TABLE meta(key LONGVARCHAR NOT NULL UNIQUE PRIMARY KEY, value LONGVARCHAR);
CREATE TABLE sqlite_sequence(name,seq);
CREATE TABLE sync_entities_metadata (storage_key INTEGER PRIMARY KEY AUTOINCREMENT, metadata VARCHAR NOT NULL);
CREATE TABLE sync_model_metadata (id INTEGER PRIMARY KEY AUTOINCREMENT, model_metadata VARCHAR NOT NULL);
CREATE TABLE insecure_credentials (parent_id INTEGER REFERENCES logins ON UPDATE CASCADE ON DELETE CASCADE DEFERRABLE INITIALLY DEFERRED, insecurity_type INTEGER NOT NULL, create_time INTEGER NOT NULL, is_muted INTEGER NOT NULL DEFAULT 0, UNIQUE (parent_id, insecurity_type));
CREATE INDEX foreign_key_index ON insecure_credentials (parent_id);
CREATE TABLE stats (origin_domain VARCHAR NOT NULL, username_value VARCHAR, dismissal_count INTEGER, update_time INTEGER NOT NULL, UNIQUE(origin_domain, username_value));
CREATE INDEX stats_origin ON stats(origin_domain);
CREATE TABLE field_info (form_signature INTEGER NOT NULL, field_signature INTEGER NOT NULL, field_type INTEGER NOT NULL, create_time INTEGER NOT NULL, UNIQUE (form_signature, field_signature));
CREATE INDEX field_info_index ON field_info (form_signature, field_signature);
CREATE TABLE IF NOT EXISTS "logins" (origin_url VARCHAR NOT NULL, action_url VARCHAR, username_element VARCHAR, username_value VARCHAR, password_element VARCHAR, password_value BLOB, submit_element VARCHAR, signon_realm VARCHAR NOT NULL, date_created INTEGER NOT NULL, blacklisted_by_user INTEGER NOT NULL, scheme INTEGER NOT NULL, password_type INTEGER, times_used INTEGER, form_data BLOB, display_name VARCHAR, icon_url VARCHAR, federation_url VARCHAR, skip_zero_click INTEGER, generation_upload_status INTEGER, possible_username_pairs BLOB, id INTEGER PRIMARY KEY AUTOINCREMENT, date_last_used INTEGER NOT NULL DEFAULT 0, moving_blocked_for BLOB, date_password_modified INTEGER NOT NULL DEFAULT 0, UNIQUE (origin_url, username_element, username_value, password_element, signon_realm));
CREATE INDEX logins_signon ON logins (signon_realm);

I then also observe that under "Passwords and Keys", which is the:

seahorse

GUI frontend for GNOME key ring, that there is a Chromium entry:

which is presumably contains the key to decrypt the passwords in the database.

That GUI also showed all my old passwords left over from previous Chromium versions, which I now nuked (and then had to reset the password database because I also nuked the Chromium key by mistake, but Google autosync saved me :-) https://superuser.com/questions/573602/chrome-not-saving-passwords-and-not-auto-filling-existing-login-passwords/1325741#1325741 )

This gets automatically unlocked at login time.

Some interesting reminders:

• you must use a strong long passphrase for your login, otherwise an attacker that obtains your computer and cracks your short password offline gets all your website passwords
• because the screen lock does not seem to lock the keyring a well equipped attack that steals your logged in computer with lock screen might be able to read RAM and decrypt your passwords I think

Tested on Ubuntu 20.10, Chromium 88.0.4324.150 snap.

GNOME keyring might be back

Today a tap popped up: file:///snap/chromium/2333/firstrun/password-en.html saying:

Password storage via the Gnome keyring has been fixed, but for it to work, you have to rename your old ~/snap/chromium/common/chromium/Default/Login Data file so that a new, working one can replace it.

We suggest you to rename it to Login Data.old. You can do so through your file manager or by opening a terminal and entering

cd ~/snap/chromium/common/chromium/Default/
mv "Login Data" "Login Data.old"

maybe it will allow Gnome Keyring to actually store all passwords once again rather than just one master encryption key?