Stop asking to unlock the keyring!

If you've installed a browser other than Firefox, you know that every time you start it up after a reboot, it asks you to unlock the keyring.

There are two fixes for that... one not recommended, one recommended.

The not-recommended method is to set a blank password for the keyring in the Passwords And Keys application (SeaHorse). Start it up, hit the back arrow at top-left, then at the top you'll see "Default keyring".

Now, you can right-click that line, but not if it's got the focus (it's a bug)... so move the focus to another line, then right-click the top line and select "Change password", and enter a blank password. That's the unsafe way of doing it.

The recommended method is to start the Files application (Nautilus), then find the .desktop file for the offending application.

Then in Terminal, type (and I'm doing this for Google Chrome, although I use SRWare Iron... I'll do Iron below):
sudo gedit /usr/bin/google-chrome.desktop

Find the line in the file that says:
Exec=/usr/bin/google-chrome-stable/

And add:
--password-store=basic

... to the end of that line. Now the application should only ask once, and nevermore. You can do that for any application.

For SRWare Iron:
sudo gedit /usr/share/applications/iron.desktop

Change the line to:
Exec=/usr/share/iron/chrome-wrapper --password-store=basic

2 Likes

Interesting ..... I use Vivaldi Browser and don't recall that ever happening to me .... and lord knows I have had to reboot way to many times ..... :rofl:

But that is a great tip ....

If you turn off auto login, which you should do anyway, Chrome won't ask you to login after a start/restart because you just did. I set the power button to Suspend so I don't have to login in the morning. Turn off lock screen at Suspend in Privacy.

If you want to secure your computer, lock, log out or shut down.

The computer is physically secure, cheap, backed up and doesn't contain critical information, so I'm not so worried about someone walking up to it and using it, or stealing it. That is, I believe, the case for most people... they don't need more physical security (as TPM, Secure Boot and all the other stuff that's been developed lately attempts to improve), they need perimeter security... their internet connection is far more vulnerable than their keyboard. Their chance of getting cracked or getting malware is far higher than the chance of someone stealing or unauthorizedly using the computer locally. Hence, auto-login.

1 Like

I never have to login except after a start/restart. I just hit the space-bar in the morning and computer comes out of Suspend.

If someone did steal it, they wouldn't be able to get into it. Google has all of my shopping and banking passwords.

This is interesting.

I take a different tack. My sensitive information (name, address, banking details, contacts, passwords, etc.) is kept on a USB stick that I carry in my pocket. It's on a KeyBak retractable key chain...

... with vinyl-coated braided stainless steel cable. I put a wire through the bottom part of the clip so it can't be easily removed from my belt.

I took it apart and unwound the cable a bit to get some slack so the memory stick sits in my pocket, not just hangs from my belt. There's a screw underneath the belt clip that lets you take it apart... but you've got to be careful, that coiled spring wants to go sproing!

I cut the plastic knob off the end of the cable, threaded it through the memory stick's hole, looped it, then used a cable crimp to secure it.

You have to slip the belt out of the metal loop, so to get it, someone would have to break the cable (not possible, that thing's strong), break the device, or take off my belt... and any of those they're crawling away bloodied.

Looks like this:

Big enough to transfer most files and to save all my personal information, connects to iPad, iPhone, Android and computer.

No sensitive information is on my computer or phone (my browser doesn't save any information, no files with sensitive information are kept on anything but that USB stick and several iterations kept on a backup drive). Both my phone and computer have USB-C ports, so it's a simple matter to plug it in when and where I need it, peruse the information, find what I want, then unplug it (actually, on my computer, I have a male to female USB-C extension cord so I don't have to remove it from my belt to plug it in and there's no tension on it from the spring).

I'm completely de-Google'd and de-Microsoft'd on computer and phone (Murena Teracube 2e Emerald).

2 Likes

That reminds me... on my Windows computer, I had a shortcut icon to a PowerShell script which zipped the contents of the 250 MB partition on the USB stick which contained my sensitive information, then saved it to the backup drive with the file name being the date and time. All I had to do was plug the USB stick in to my computer, double-click the icon, and my sensitive information was archived.

Is there a similar way of doing that in Linux?

Certainly, You can create a bash script to accomplish your task, then create a desktop launcher with an icon for it.

1 Like

Looks like I'll have to learn a whole new programming language. I had the Windows version set up so it automatically searched the drives for that folder's name (so no matter what drive letter the USB stick landed on, the backup worked... a brute-force approach, to be sure)... I think for the Linux version, I'll reference the partition by its PARTUUID. That'd simplify things greatly.

You can see all your PARTUUID's with the sudo blkid command in Terminal.

Not sure how to parse those PARTUUIDs out of the string, though... they vary in length.

Ah, figured it out:
sudo blkid | grep {PUT YOUR PARTUUID HERE} | sed -e 's/^(.):.$/\1/'

Returns:
/dev/sda1
/dev/sdc2
etc.

Then we want to do a mount with the device path and node (for instance: /dev/sda1) as input to get the mount path, yes? That gives us the path and directory that zip will understand.

sudo mount | grep /dev/sdb1 | grep -o -P '(?<=on ).*?(?= type)'

Returns:
/media/owner/WinBackUp

Then we can get zip to work on that path, directory and subdirectories.

1 Like

I did this and after reboot, my Chrome browser forgot all stored passwords. I undid the changes and luckily the passwords appeared back.

You can try --password-store=gnome

I just tried and the good part is that with it, Chrome remembers the passwords, but the bad part is, it still asks to unlock the keyring at reboot (more than just once).

Nuts...

I need to go and do some work and much as I personally dislike a video guide...

I realize it is a few years old and you will see different UI

But, the application is Seahorse on Zorin OS. The principle of what he is showing as the same, even on the newer Zorin OS.

1 Like

Thanks for the reply.

I did some online research and they say --password-store=basic or --password-store=gnomestopped working within the past year.
I verified that in both of my installations: Core and Lite, 17.3.

The method with "Passwords and Keys" (Seahorse) worked in both Core and Lite, except that in Lite, app is not installed by default, so I installed it using Software app.

However, the method I used was slightly simpler, which I guess is more frequently seen around:
changing the password to empty on the "Login" folder (left side in main page of Seahorse), as opposed to creating a "Default keyring" folder and doing so on it.
Here's the simpler "Login" folder version:
https://linuxconfig.org/how-to-disable-keyring-popup-on-ubuntu
Here's the "Default keyring" folder version - the non-video page for your linked video:

Is the latter version better / does it matter much?
My guess is that it may be better, if you need the Login folder to remain properly locked with a proper password, for some other needs than browsers' storages.

1 Like

As an experiment, I uninstalled "gnome-keyring" in Zorin Lite - nope, then Chrome browser could not recall my passwords, even though I was signed-in.
Thus re-installed that back, and re-applied the solution with Seahorse => all good.

But auto-login, together with either of the solutions to stop the request to unlock the keyring at browser start, means that the browser's locally stored passwords are no longer encrypted.
At least that's the warning I got in Seahorse when making the password to the keyring to be empty; it added that the passwds would be accessible by anyone with access to the files.

Doesn't that mean that those passwords are also more vulnerable to malware?

EDIT:
On the other hand, how is auto-login and that keyring's encryption helping against malware, if, once logged in, the keyring's files are "unlocked" - so that the browser can access those passwords. If the browser can, then so some malware?

This is why the goal is to prevent malware from establishing itself in a system as the first security measure.

Yes, Auto login weakens this, because if a thief steals your computer, it will auto-login when that thief powers it on.

As to the rest of your question, you are technically correct - the passwords are encrypted if auto login is not used and a blank keyring is not used, preventing them from External Access.
And this prevents access if a thief steals your computer.

If, however, Malware is present on the user account, then it has already managed to get through multiple layers of security.
At that point, when you enter your password and decrypt the Browser saved passwords - it can access them or whatever else it is programmed to access.
This is why multiple security layers are in place.

And why I recommend against Auto Login and other security weakening steps that a user may wish to take, for a couple seconds of convenience.

It's a matter of weighing your risks against your convenience.

1 Like

With the last question, I had in mind malware off the internet.
I started to suspect as much: that gnome-keyring is not effective against that.

It's a matter of weighing your risks against your convenience.

Well-said; and the balance can be different for different people.

I think auto-login would be more acceptable if you had a "real lock" feature that you could activate on purpose (ex, when leaving laptop unnattended), with a shortcut, iand which would not only lock, but also disable auto-login (plus perhaps other related security steps).
While unlocking would re-enable auto-login.

For other Lite (or Xfce) users who had enabled auto-login during installation:
Here's how I was able to disable it (there's no GUI option):
sudo nano /etc/lightdm/lightdm.conf
and commented out the line with "autologin-user=userName":

[Seat:*]
autologin-guest=false
#autologin-user=userName
autologin-user-timeout=0