I use Chromium browser in 2 different distros, namely Manjaro and EOS. When I import my passwords from the same .csv file, 2 different things happen. With EOS all the password accounts are visible and remain so with repeated use of Chromium. In Manjaro’s case the password list remains visible for just one occasion until I exit Chromium. But if I run Chromium again in the same session or otherwise, the password list becomes hidden and stays so.
I’ve always found that with Manjaro, and assumed that this was some built-in security feature to prevent myself (or others) gaining direct access to my website passwords. If I ever needed to look up a password I had the .csv file which I keep encrypted on my drive. However, because of autofill I rarely needed the csv file anyway.
But with EOS, the password list doesn’t become hidden after I reload Chromium. Consequently there’s no security, other than logging in to my user account to use the computer. So once Chromium runs, anyone can see my passwords. But I can add an extra security layer by using KWallet to set a password to log into Chromium although I only need to login once per session.
So as I can’t see Chromium’s password list in Manjaro, and I have not used any additional security, is my password list properly protected?
I have used it in the past, before kwallet became the default way of doing things in Plasma, and when you then looked at chromium’s stored passwords, they were masked out with asterisks, but you could make them visible (and hide them again) by clicking on the icon next to each password.
As I recall, the visible or hidden state of the passwords was persistent across chromium restarts, so once they were visible, you had to explicitly toggle them to hidden again using the icon, or they would remain visible.
The short answer is yes your password list is properly protected.
The longer answer
Passwords in Chromium is managed by the Password Manager WebApp.
Anyone with/knowing your credentials to the system will be able read those passwords.
In a default install Chromium will create a key in the systems keyring.
Unless you have activated autologin that keyring is unlocked when you sign on to the system.
When Chromium has access to the unlocked system keyring it will use the information stored in <keyring>/Chromium Keys(1)/Passwords/Chromium Safe Storage to read the passwords stored in the sqlite file ~/.config/chromium/Default/Login Data.
If you look at the sqlite file using e.g. Midnight Commanders View function you will see the data Chromium stores relating to passwords - site, username, password etc. - but do note - the password column does not contain the password in clear text - it is obscured - and the content is only readable by Chromium.
The Chromium key in the keyring is unique for every system that has Chromium installed.
You can test the assumption by copying the file Login Data from Manjaro to EOS.
As the key in the keyring is different from Manjaro and your EOS replacing the file Login Data will not allow the content to be correctly read - the key is wrong.
Got to love those Space Invaders in the filenames … presumably typical (ex?) M$ “programmers”.
Oracle (VirtualBox) is also guilty … there at least used to be a config file one could edit to stop that one auto-creating such “naughty” paths/filenames.
icon next to each password.