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?
Chromium and Chrome
Store passwords in three ways:
- GNOME Keyring
- KWallet 4
- 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.
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.
Your passwords are stored in the key4.db and logins.json files.
Ubuntu 20.10 Chromium stores passwords at
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
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:
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
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:
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.