GNOME Cleartext Passwords: Bug or Feature?
The current discussion in the Ubuntu forums is about a possible security hole in GNOME, specifically about GNOME registered users having their passwords appear as cleartext on the keyring. Not a bug, say its defenders, but the security concept behind the GNOME keyring.
In the discussion thread, the discoverer of the "blatant security flaw" gave an example of how it happens in Ubuntu 9.10. The user starts Ubuntu and registers on the desktop. The path through the Applications | Accessories | Passwords and Encryption Keyrings menus arrives at the keyring manager. Clicking on the Login folder shows the application processes and programs (including WLAN and mail accounts) and their respective passwords.
A right mouse click on an entry shows a context menu of properties, one of its tab being for keys. Clicking Password pops up a screen asking whether keyring access is allowed, for which no restrictions exist. The passphrase then appears and can be viewed as cleartext.
Critics of this approach provide a scenario whereby a profile owner has multiple users allowing access to the account. Operating in WLAN mode he wants to ensure that his keyring passphrase is secure. The suggestion is to further secure it through the user password so that guests need to know the profile owner's password before discovering what the keyring passphrases are. As it is, so goes the argument, users without much technical knowhow can easily steal the passphrases, so that additional password protection would deter "99% of potential identify thieves."
Defenders of the GNOME keyring strategy assure that only registered users have access to passphrases, the solution being to "lock your screen if you walk away." Defenders refer to the gnome-keyring security philosophy that suggests just that: locking the screen and creating guest logins. For those who still consider this a problem, so far no hard and fast solution exists. However, it is being actively discussed, among other places in the gnome-keyring mailing list.
Comments
comments powered by DisqusSubscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
There's a New Open Source Terminal App in Town
Ghostty is a new Linux terminal app that's fast, feature-rich, and offers a platform-native GUI while remaining cross-platform.
-
Fedora Asahi Remix 41 Available for Apple Silicon
If you have an Apple Silicon Mac and you're hoping to install Fedora, you're in luck because the latest release supports the M1 and M2 chips.
-
Systemd Fixes Bug While Facing New Challenger in GNU Shepherd
The systemd developers have fixed a really nasty bug amid the release of the new GNU Shepherd init system.
-
AlmaLinux 10.0 Beta Released
The AlmaLinux OS Foundation has announced the availability of AlmaLinux 10.0 Beta ("Purple Lion") for all supported devices with significant changes.
-
Gnome 47.2 Now Available
Gnome 47.2 is now available for general use but don't expect much in the way of newness, as this is all about improvements and bug fixes.
-
Latest Cinnamon Desktop Releases with a Bold New Look
Just in time for the holidays, the developer of the Cinnamon desktop has shipped a new release to help spice up your eggnog with new features and a new look.
-
Armbian 24.11 Released with Expanded Hardware Support
If you've been waiting for Armbian to support OrangePi 5 Max and Radxa ROCK 5B+, the wait is over.
-
SUSE Renames Several Products for Better Name Recognition
SUSE has been a very powerful player in the European market, but it knows it must branch out to gain serious traction. Will a name change do the trick?
-
ESET Discovers New Linux Malware
WolfsBane is an all-in-one malware that has hit the Linux operating system and includes a dropper, a launcher, and a backdoor.
-
New Linux Kernel Patch Allows Forcing a CPU Mitigation
Even when CPU mitigations can consume precious CPU cycles, it might not be a bad idea to allow users to enable them, even if your machine isn't vulnerable.
It is a massive hole
There are many environments where this level of incompetent insecurity is simply unacceptable, where as a consequence Linux is unacceptable - including environments with a Clear Desk Policy which I have worked in.
Useless