GNOME Bugzilla – Bug 685395
Wireless passwords stored in plain text
Last modified: 2020-11-12 14:34:52 UTC
Please see upstream bug https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1060907 Storing passwords in plain text is a major security flaw that cripples the use of Linux laptops in our organization. We want our users to be able to connect to existing hotspots, but this require giving them access through org.freedesktop.NetworkManager.settings.modify.system. Giving them access to this allows them to make changes to system connections and in effect makes it impossible to prevent storing of plain text passwords. Had this been only random wep/wap keys it would not be a big deal, but we use eduroam. Eduroam (education roaming) is the secure, world-wide roaming access service developed for the international research and education community. This uses our standard user credentials. The result is that nm compromises the password of anyone connecting to eduroam. "Protecting" this by requiring root access is no protection. Several people have rook keys and sudo rights on our machines. And while we do grant our administrators a lot of trust we can not and will not hand them plain text passwords.
We've been doing work in Debian to address that use case, that of untrusted users. While we do ship a PKLA file which you can use to grant users the org.freedesktop.NetworkManager.settings.modify.system privilege without an admin pw prompt, we explicitly also support that you don't grant that rights. In that case, the NM client (gnome-shell, nm-applet, g-c-c) fall back and create user-owned connections. In that case the secret is stored in the gnome keyring. If you are interested, you can pull the patches from [1] or simply use Debian wheezy :-) [1] https://bugzilla.gnome.org/show_bug.cgi?id=646187#c46
I am also having issues with this. In my use case, with NetworkManager-1.0.9.6.4-3.fc17 (64-bit), I have a VPN connection for a non-root user which is set to NOT connect automatically and NOT allowed on a system basis. If I do not enter a passphrase I cannot save the VPN configuration. If I do add a passphrase it is stored under /etc/ with only root permissions rw permissions as 'protection'. As far as I remember,I was not offered the option to store to keyring when I set it up - nor would I want it to. There seems to be an implicit requirement in the design, or belief in the authors, that the password should be stored - I have no idea why this should be. There is further the belief that storing it as plain-text is as safe as it needs to be - perhaps if you're storing it in /etc or in the users keyring that's true, but there is life beyond them.. which is just as well given their limitations. It used to be possible to create configurations without passwords/passphrases, which lead to a prompt for credentials when making a connection using such a configuration - this seems eminently sensible, especially if the passphrase can be protected in memory or otherwise safe-guarded (as done elsewhere). That this ability it no longer there, it would seem to indicate that there was a conscious decision to remove it - if so, can I ask what the thinking was behind it ?... if not, why was it then removed ?
(In reply to comment #2) > It used to be possible to create configurations without passwords/passphrases, > which lead to a prompt for credentials when making a connection using such a > configuration - this seems eminently sensible, especially if the passphrase can > be protected in memory or otherwise safe-guarded (as done elsewhere). That this > ability it no longer there, it would seem to indicate that there was a > conscious decision to remove it - if so, can I ask what the thinking was behind > it ?... if not, why was it then removed ? You can still create connections where the secrets are stored in the user keyring (gnome-keyring or kwallet). It's just that system-wide connections are the default nowadays.
(In reply to comment #3) > (In reply to comment #2) > > It used to be possible to create configurations without passwords/passphrases, > > which lead to a prompt for credentials when making a connection using such a > > configuration - this seems eminently sensible, especially if the passphrase can > > be protected in memory or otherwise safe-guarded (as done elsewhere). That this > > ability it no longer there, it would seem to indicate that there was a > > conscious decision to remove it - if so, can I ask what the thinking was behind > > it ?... if not, why was it then removed ? > > You can still create connections where the secrets are stored in the user > keyring (gnome-keyring or kwallet). It's just that system-wide connections are > the default nowadays. I'm questioning the requirement to have mandatory, persistent storage of the security credentials - not which is the best way of doing so (or any other nonsense). IMO, and apparently some others i've seen commenting on this matter, not only is there no such requirement but having such a requirement also serves the make the user interaction more cumbersome and the system prone to security breaches.
(In reply to comment #4) > I'm questioning the requirement to have mandatory, persistent storage of the > security credentials - not which is the best way of doing so (or any other Are you saying you want to type in the WPA-PSK or WEP-key on each connection attempt?
(In reply to comment #5) > (In reply to comment #4) > > I'm questioning the requirement to have mandatory, persistent storage of the > > security credentials - not which is the best way of doing so (or any other > > Are you saying you want to type in the WPA-PSK or WEP-key on each connection > attempt? For each session - yes. Users of OTP stacks for access will as well. IIRC, conceptually this was the way it used to work in NetworkManager a while back. The details of credential storage during a session is another matter (one i'm happy to chat about) but that was one of the usage models available. This seems to have been removed... unless i'm missing something ?
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > I'm questioning the requirement to have mandatory, persistent storage of the > > > security credentials - not which is the best way of doing so (or any other > > > > Are you saying you want to type in the WPA-PSK or WEP-key on each connection > > attempt? > > For each session - yes. Users of OTP stacks for access will as well. IIRC, > conceptually this was the way it used to work in NetworkManager a while back. > The details of credential storage during a session is another matter (one i'm > happy to chat about) but that was one of the usage models available. This seems > to have been removed... unless i'm missing something ? WPA-PSK and WEP keys have always been stored IIRC. For other type of connections (VPN, WPA-Enterprise) which require username/password, you can still configure if the password is either stored or always prompted for
(In reply to comment #7) > WPA-PSK and WEP keys have always been stored IIRC. > For other type of connections (VPN, WPA-Enterprise) which require > username/password, you can still configure if the password is either stored or > always prompted for I cannot find a way to create a VPN configuration that does not include a password/phrase through NetworkManager - that being one of the main issues. As detailed earlier - you cannot save a configuration without a password/passphrase and if you do supply one, it is stored insecurely. In addition, the configuration I made was not a system wide one, yet seemed to be stored under /etc. If you know of a standard user interface under GNOME that allows VPN connections to be created with no stored passphrase, and which prompt for credentials on a per-connection/session basis - i'd be very interested to hear. NetworkManager does not appear to be such a thing (which is unfortunate as it's the one activated by default).
(In reply to comment #0) > Please see upstream bug > https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1060907 > > Storing passwords in plain text is a major security flaw that cripples the use > of Linux laptops in our organization. > > We want our users to be able to connect to existing hotspots ... > > Had this been only random wep/wap keys it would not be a big deal, but we use > eduroam. Eduroam (education roaming) is the secure, world-wide roaming access > service developed for the international research and education community. This > uses our standard user credentials. The result is that nm compromises the > password of anyone connecting to eduroam. > > "Protecting" this by requiring root access is no protection. Several people > have rook keys and sudo rights on our machines. And while we do grant our > administrators a lot of trust we can not and will not hand them plain text > passwords. My educational organization is similarly affected. We'd like to deliver a configuration package for our existing WPA2 Enterprise network, and Eduroam someday as well. While always distasteful, plaintext password storage is flatly unacceptable in this environment -- here our single sign-on system means that an employee uses same username and password to access the wireless as to change her payroll direct-deposit.
As the noted security issue is about the *root* user having access to stored credentials, I don't think we need to track it as a critical issue. The developer documentation of NetworkManager describes password storage attributes and it's clearly possible to avoid storing passwords. If that doesn't work, it should be reported properly. If the problem is in some of the available UI tools, it should be reported against that tool. Please add more specific feedback so that we can decide whether it makes sense to track this issue with the NetworkManager daemon. Any thougts, Michael?
Alternate solution would be to implement user connection - bz#646187 .
I think someone should just check whether you can configure that the credentials must be entered at connection time or not. For that, you will need to specify how exactly is your wifi configured. Michael already stated that WPA2 Enterprise supports that.
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).