GNOME Bugzilla – Bug 551036
seahorse shows passwords without verification
Last modified: 2021-06-18 10:40:48 UTC
Please describe the problem: When I log in the first time, I get asked for my password to access the wireless network. Then any time later I can run seahorse (without authentication) and go and look at my wireless password (password tab / passphrase for wireless network / properties). It just asks me 'Do you want to allow access?' and if I say yes (ie 'Allow Once' or 'Allow Always'), it doesn't ask for authentication or anything, it just shows the password. Isn't this a security problem? If I reboot just X with CTRL-ALT-BS and log in again, when I run seahorse it asks me for authentication to run it, but after a full reboot it doesn't ask for any authentication. I have automatic login enabled (so on full reboot I don't need to login via the X login window) if that makes any difference. Steps to reproduce: Actual results: Expected results: Does this happen every time? Yes Other information: This bug was reported on Launchpad: https://bugs.edge.launchpad.net/ubuntu/+source/seahorse/+bug/189774
I can confirm this too. The "Show in clear text" check box is very very unsecure. Anyone having access to your computer can sit, run seahorse and READ YOUR PASSWORDS IN CLEAR TEXT stored in the 'login' keyring after having clicked 'Allow Once' or 'Allow Always' in the unsafe 'Do you want to allow access?' dialog. I checked how this issue is handled in Mac OS X's keyring application and it solves the problem by always asking keyring's unlock password if you request to read a password in clear text. To summarize: Every time a user wants to read a password in clear text, seahorse SHOULD ALWAYS request keyring's unlock password before displaying it.
I agree this is a problem. It's a difficult one to solve. There are also extreme wishes on teh other side: http://bugzilla.gnome.org/show_bug.cgi?id=533493
Remember, anyone having access to your computer (X session) can also install a keylogger trojan. We already have a password entry field protecting private data for a running session - it's called gnome-screensaver.
I agree anyone having access to the computer can do nasty things, but on the other hand, practically, leaving access to a computer in a family to friends or other people without a specific login is also quite common for normal house users who are not "paranoid" (please see no offense in this expression). One way to solve this issue is to remove the "Show password in clear text" feature from seahorse. This especially make sense if seahorse goal is to store application passwords. But I admit that in rare cases, it is useful to read the password in clear text "because we have forgotten it as we do not type it very often". In this case, I suggest that seahorse always request keyring's unlock password for the operation. (The "Allow once/always/Deny" dialog is not useful here).
I agree that Show password in clear text is very insecure. One thing is when somebody gets access to my computer and read my email once, other thing is when he writes down a password(with ease thanks to seahorse) and browse my email from anywhere. Fixing this issue is so simple - just ask for password before displaying the password.
It's not very, very simple, and I believe that stems from some confusion as to what's happening. gnome-keyring stores the secrets and access control lists about applications and what they can do with each secret (read, write, delete). The dialog presented when the password expander is toggled comes from gnome-keyring and is giving seahorse one time or all time access to the secret but doesn't ask seahorse what it's doing with the secret (using it, displaying it). This is the exact same dialog any application/user querying the keyring would recieve when your keyring is unlocked. If your distribution or self install uses the PAM module, your keyring is unlocked when you login, locked when your screen is locked, unlocked when you unlock your screen and locked when you log out. This is usability at the cost of security (i.e. you don't have to enter the unlock password after logging in). You can easily disable this feature by changing the password of your keyring to something other than your login password or disabling the PAM module. You will now be asked to unlock your keyring every time an application wants to use a secret (including right after login when NM wants to connect to your secured wireless network). There is no "right" security model for everyone and perhaps the real solution is to have the screen lock by default when the screensaver engages so that the default security model is more consistent. Like Pierre said anyone with X access to your computer can do plenty of nasty things, including query gnome-keyring from the command line or run an application to get the same info as seahorse.
I see now how complicated this problem is to solve. Apparently the problem lies on different security approach that gnome-keyring use than others. Is it possible to make Seahorse ALWAYS trigger prompt for password when the user want reveal the password in clear text? I think it does. The primary goal of this issue is to prevent the password from being stolen by ordinary non-skilled users. So any password-access solution should do. It doesn't have to be encrypted or so.
If I see Firefox's security model. I think it looks similar with gnome-keyring. In Firefox, when master password are set, revealing password in clear text requires master password. I think that is quite good solution if can be applied nicely.
Ok if I understand well what Adam says, when keyring is unlocked, any program having the read access right for a secret can read it from gnome-keyring. If the program does not have read right, the "Allow/Deny" dialog pops up and the user can grant it this right (temporarily or permanently) **without entering keyring's password**. Maybe a solution would be to always request keyring's password to "Allow (once or always)" a program that has no right so far to read a secret, **even if keyring is unlocked**. If "Allow Once" is chosen and keyring's password is correct, read right is granted for this time but program is not added in access control list for this secret. If "Allow Always" is chosen and keyring's password is correct, program is granted read right in access control list for this secret and future read attempts would be always be granted if keyring is unlocked. It would be user responsibility to not "Allow always" a program that should not be allowed to access a secret permanently if keyring is unlocked. If gnome-keyring worked this way, clicking "Show in clear text" in Seahorse would pop up the Allow Once/Always/Deny dialog with an additional password field requesting keyring's password to perform any "Allow" action (once again **even if keyring would be unlocked**). It would be user responsibility to allow only once access to seahorse to avoid future unwanted reads. To summarize in another way, unlocking keyring would grant any program with permanent rights to do what they are allowed to but **not to add new rights (temporarily or permanently) to a program without requesting keyring password again**. Does it make sense?
Linking some interesting reads, before continuing this discussion. Especially the point about, put another way, on most Linux desktops, the entire login session is one security context. http://live.gnome.org/GnomeKeyring/SecurityPhilosophy http://live.gnome.org/GnomeKeyring/StoringSecrets
*** Bug 583484 has been marked as a duplicate of this bug. ***
I wrote this on the ubuntu branch of this bug to escalate the seriousness of this flaw: ============================================================== I see this as a VERY serious security flaw! Given that Empathy Instant Messenger is going to be the default messenger in the next Ubuntu Release, I thought I'd check it out. While setting up my gmail and msn accounts I noticed that it was saving the passwords in the public keyring. It was also giving the familiar quickAllow ("Deny","Allow Once", "AllowAll") dialog when starting up the program and connecting to these accounts. No prompting for any password to protect the keyring. Given that this was being stored in a public keyring, I wanted to see how easy it was to find these password. I open up sea horse, and hey presto! My passwords to gmail and msn are available for all to see for someone who might be strolling around my workstation/laptop while i'm not there, (if I forget to log out or lock)... using the quickAllow dialog. Now if someone finds my wireless network key, I don't really care in the scheme of things, even if they use my network to commit bad acts, it happens often enough that I'm unlikely to be penalized. However! I and most people have very sensitive information in our webmail accounts and easy access to them is definitely something I'd like to avoid. It looks like the quickAllow dialog is from some common library that both applications call into. Please can this prompt for a password, the same way as critical updates do!!! Thank you. ============================================================== Okay. I've now read through the complications of this process on the gnome bugzilla page, including the links GnomeKeyring Security Philosophies. Quite simply, you cannot solve this problem in a way that solves both -usability- concerns and -security- concerns if you don't have Security Contexts for different apps AND Acls for different apps to remember which ones can access what (require passwords, always have a access to passwords). It seems to me that the section about Active attacks expresses the attitude that up till now endeavouring to provide these functionalities has not been worthwhile. Hopefully this opinion will change now that it will become far more common for sensitive information to be stored in the GnomeKeyring. Re:Firefox I was dismayed to find that firefox allows all passwords to be displayed through the UI by default. Of course I knew since there was no prompting for a master password initially that it was possible to get to the data, I didn't think that it would be so easy through the UI. I regard this as the App giving a false sense of security. After managing to steal some co-workers passwords and showing them, I've now set a master password for the few passwords I save in the app.
A possibly interesting solution is outlined in the following comment: https://bugs.launchpad.net/ubuntu/+source/seahorse/+bug/189774/comments/9 It involves using policykit to enable keyring access for only predesignated apps.
That solution involves running gnome-keyring as root, as a system service rather than in the user session. An interesting solution none the less, and we can look into the benefits and drawbacks. But it's important to realize this is a complete architecture change, and would require lots of redesign and recoding.
Can somebody please explain why there is a GUI option to display passwords in plain text in the first place, regardless of what how you may gain access to it?
Wouldn't this be much simpler if it were a bug in seahorse instead of gnome-keyring? Seahorse should simply be expected to prompt for a password before displaying a key's plain text password. Gnome-keyring's behavior does not need to be changed it will still display the deny, allow once or always prompt as it should. Getting two prompts is a little annoying but is a better solution than having passwords in plain sight. I would like to welcome anybody in my house to use my computer which seems stupid if its that easy to access all of my passwords. ishnid@gmail.com: it is very helpful to be able to see passwords in plain text occasionally. For example if a friend wants to get on my wifi network it is much better and easier to have the password on my computer than to need to find it written in my house somewhere.
I know there must be hundreds of ways to get your privacy compromise if some one uses your computer while you are gone, but you don't have to be a computer genius to open seahorse in less than 30 secs. In my opinion, there is different computer levels, I feel I'm just in the desktop level, and the fact that using the mouse is all you have to know to open seahorse and watch somebody else password doesn't feel right to me.
We are not allowed to give our users the WIFI Code. We set it up for them and they should not be able to access it but the keyring allows them to see the code in plain text. and without access to the keyring they cant access the WIFI. Its Simply a deal breaker for using linux in our environment.
(In reply to comment #18) > We are not allowed to give our users the WIFI Code. We set it up for them and > they should not be able to access it but the keyring allows them to see the > code in plain text. and without access to the keyring they cant access the > WIFI. Its Simply a deal breaker for using linux in our environment. I think you might be able to restrict this with NetworkManager 0.9 since the connections are system wide, not per user.
*** Bug 617332 has been marked as a duplicate of this bug. ***
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/ Thank you for your understanding and your help.