Please stop storing passwords in /etc ever. This is the default behavior.
Unless someone explicitly requests that and is properly warned about about the consequences, it is generally not acceptable to have security relevant data stored on disk.
I hope you succeed in getting this fixed. A similar report in debian got shot down with ungodly speed (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647644 )
I don't understand the developer's idea of security - I quote: "Those passphrases are only readable by root resp users with admin
privileges, so there is no user security hole.
And you can certainly create connections, where the password is stored
in the user session."
1) since we're talking wireless, we're probably talking about a laptop or other similar single-seat machine where the non-owner user can physically access the hardware;
2) therefore, protecting something with "root access" is no protection at all, since it takes all of 2 minutes for said single-seat user to boot a USB stick and access the CLEAR TEXT PASSPHRASES stored by network-manager in /etc/NetworkManager/system-connections, then boot back into the normal system;
3) creating a non-system connection is NO PROTECTION since the network's owner would have to create the connection in each user's session, where said user can simply use seahorse to display the passphrase in clear text;
4) so the fallback answer would be "well then, encrypt your whole hard-drive"; and hopefully you're able to be present to enter the decryption passphrase everytime the local user reboots the machine!
5) I don't understand why even though the system takes pain to store users' passwords in hashed/encrypted form in /etc/shadow, that kind of security is somehow not needed for NetworkManager's secrets...
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.
(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)
More information and reason for this action is here:
Your logic fails at step 5. With /etc/shadow passwords the computer is verifying the password. The user is entering it in plain text. Now think about getting a wireless network. The network AP is verifying the password. The client, aka your computer, must enter the password in plain text. So how can your computer give the password in plain text if it doesn't store it somehow?
If having it live on disk in plain text is unacceptable we really only have 2 options. Encrypt the disk. Don't store the password on disk. Thus you'll have to enter it every time you want to get on Wifi. Not sure if NM offers that option, but I wouldn't use it even if it did *smile*
I guess a third option exists, storing them in the gnome keyring. But this means no network connections until after you log into the machine. I'd be fine with this for some of my machines, but not others...
So, how hard is to just encrypt somehow these passwords? This is still true in Fedora 20. Also, i suspect is also true for pppoe passwords.
You can't encrypt the passwords and store them system-wide because the plain text versions are needed to authenticate with the network. You could store them per-user in gnome keyring as suggested, and then they will be protected by the keyring pasword (usually the same as your user password).
Let me guess, does a network you connect to require you to use your regular system/domain login password? Is it using PEAP? Because that is the real problem--wifi connections shouldn't be tied to system or domain logins and EAP-TLS should be used with per-device certificates instead. But since this isn't something a user could control, there should be a better option in NM to handle this case. Maybe the defaults for PEAP should be per-user-only and only allow system-wide connection configuration from the nm-applet after a big fat warning is displayed.
This message is a notice that Fedora 19 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 19. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 19 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.