Linux Distributions Storing Wi-Fi Passwords In Plain Text 341
Bill Dimm writes "An article on Softpedia claims that Linux distributions using NetworkManager are storing Wi-Fi passwords in plain text in /etc by default. The article recommends encrypting the full disk or removing NetworkManager and using a different tool like netctl. Some of the article comments claim the article is FUD. Is this a real problem?"
From a comment there (Score:5, Insightful)
While it is true that the passwords are stored as plain text, in order to view the "plain text" one must have root privileges to view the text file.
I would venture to state that "if" one's system is open enough (a stranger has root privileges) for some unwanted person to view that text file, then one has much more to worry about than the fact that one's wifi password is not encrypted.
Also, to fix it, one must disable the "Available to All Users" option... thus requiring one to enter one's password for wifi on every login... which is annoying to say the least.
Personally, I think the issue is pretty much a mountain out of a molehill... because, and again, if to view it, you have to be root, then the whole system is vulnerable and not just the wifi password.
Which completely ignores security vulnerabilities in Linux, as many advocates do. Still, the relevant point is that for someone to steal your wifi password this way, they're already in position to do much worse.
Security - and a false sense of security (Score:2, Insightful)
The OS has to be able to decrypt the password to connect to the wifi network.
Windows stores the password as an (unencrypted) hex string in the registry. Guess I've gotta go with full-disk encryption then...
It's true -- but only root can read them though. (Score:1, Insightful)
The basic fact is true - they are there in plaintext.
But since only root can read the file, it doesn't mean much in terms of a security hole. If the attacker is already root, they have access to everything on your system anyway.
Re:From a comment there (Score:4, Insightful)
Re:Has been for years. (Score:5, Insightful)
It is secure with regard to the design specification. The client does need to have the plain-text password or it cannot authenticate itself. If you do not want a plain-text password to be available to the entity storing it (and that is what password protection is all about), then you cannot use a mechanism where the plain-text password needs to be supplied. At best this is a Wi-Fi protocol vulnerability.
Re:It's true -- but only root can read them though (Score:5, Insightful)
If someone has physical access to your drive, you have much, much worse problems than someone sniffing your WiFi traffic. To do this, someone has trespassed into your house. I'm much more concerned with strangers stomping around my living room than I am about someone sniffing my WiFi traffic.
Re:From a comment there (Score:5, Insightful)
No, it does not. Have you actually read the part "" one's system is open enough (a stranger has root privileges) for some unwanted person to view that text file, then one has much more to worry about than the fact that one's wifi password is not encrypted."? Apparently not. As the password has to be available in plain at the authentication time, this nicely sums up, why the password storage is not a problem. But to understand that, you would actually need to have a minimal clue what you are talking about...
Re:Alternative? (Score:4, Insightful)
If you're bitching about having to enter a password ONCE after logging in then you don't even belong in the discussion.
Slightly off-topic, but - If I entered a password to log in, why do I need to enter another?
Re:FUD (Score:3, Insightful)
NetworkManager doesn't follow the Unix philosophy, and was made by and for a younger point-and-drool generation grown up with kitchen sink apps with camel case names and MSDOS configuration files.
In short, it is an atrocity that does not belong.
As for storing the password in plaintext, it should not store it at all. The admin should store the credentials, not the app. In a file with read access for only the app that needs it, and no gratuitous root privileges when not needed. This dumbing down to make it easy for users and overuse of root access by apps must stop.
Re:From a comment there (Score:4, Insightful)
This.
This comes up all the time, and people are always shocked and horrified that certain data are stored in plain text. They want instead for magic encryption dust to be sprinkled on things. But often it's the case that there is no reasonable alternative. Data like WiFi passwords have to be available in plain text at the time they are used. If your system is configured so that a WiFi connection should be available to any user (or if it should be connected at boot time, before user login), then it must be available in plain text. If you encrypt it, the same party that would have had access to the plain-text form instead needs access to the encryption key, which means that the encryption is doing nothing.
There are some design failures that could be improved. User-specific WiFi connections can have their passwords encrypted, but they are often not as well-supported or well-designed as they should be. User-specific networking configuration in general under Linux is not very well supported (to be fair, it's tricky), but it's a good option for any really multi-user system.
Encrypting the whole disk is certainly an option, as the article points out, but it's solving a different problem. There's tons of plaintext data that your system needs to have access to that's potentially sensitive. That's the nature of the system. You can't realistically encrypt it from the perspective of the "live" system -- the live system would just need the encryption key, too -- but you can encrypt the disk, which encrypts it from an attacker that has access to the powered-off hardware. However, a) this is a much broader protection than solving "WiFi passwords aren't encrypted", b) if an attacker has access to your hardware, realistically, WiFi passwords are the least of your concerns, and c) full-disk encryption can be tricky to do right on laptops, which are the main user of WiFi.
Re:FUD (Score:5, Insightful)
Then you don't regularly communicate with remote git, Subversion, CVS, FTP SFTP, FTPS, or HTTPS websites with passwords. Even SSH and SSL key management is vastly improved by having some kind of graceful keychain to unlock, and release, keys as needed. The command line tools are too awkward, even for me, to consistently handle them across a wide range of application I might use in a day.
Re: KNetworkManager (Score:4, Insightful)