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?"
KNetworkManager (Score:5, Informative)
Simple. Stop using Gnome shit.
How can I store passphrases associated with encrypted wireless networks?
The first time KNetworkManager is used, it will try to set up the KDE Wallet (encrypted password storage) to save wireless network passphrases and other passwords. If you choose not to use KWallet, KNetworkManager will store passwords in its configuration files, only readable by the logged in user.
http://old-en.opensuse.org/Projects/KNetworkManager#Wireless_LAN [opensuse.org]
And the problem is? (Score:2, Informative)
I'm sorry that timothy and the submitter are morons without a clue, but in order to auto-connect to a wifi network without entering your password every time, the wifi key HAS to be readable by the system. Theres no POINT in encrypting it if you aren't entering the password EVERY TIME you connect, otherwise the password may be obfuscated but always available in plain text with little work considering you have the source so you know EXACTLY how the system extracts it.
--BitZtream
FUD, I am a fraid (Score:5, Informative)
Generally, storing passwords on the verifying machine in plain is a really bad idea. This is not the verifying machine. On the supplying machine, you usually do not have a choice but allow access to the plain-text password, how else would it be supplied? Hence, while you can store it encrypted, that encryption must either be automatically reversible (making it pointless) or protected by an additional password the user enters each time (making the storing pointless).
So, no, these people crying "insecure" do not understand what they are talking about and do not know that either (Dunning-Kruger Effect at work). This particular kind of incompetence has seen an increase with the Snowden-relevations, where people with no clue about IT security, risk evaluation or crypto do "pattern matching" with a list of "bad" things in crypto, like "password stored in plain", "SHA1" and then claim insecurity when the keywords turn up in something. They are basically always wrong, because they do not even begin to understand the specific use of the mechanism. Typically the do not even have beginner-level knowledge, like these cretins here. Otherwise they would have understood that Wi-Fi does not do a challenge response authentication with a shared secret, but a plain, one-way password submission. For these, the password does need to be available in plain or things cannot work. Instead, these idiots cry "insecure".
The only possible other explanation I have is that these people are NSA shills that try to confuse the issue.
SSH Keys Also Vulnerable (Score:5, Informative)
It is also common in most Linux distros to store SSH private keys in ~/.ssh, which -- given you need root to read the wifi passwords -- can be accessed just as easily. Access credentials have to be stored in the clear somewhere on a live machine -- in memory during connect if nowhere else. Once you root the box, you get everything.
Re:Security - and a false sense of security (Score:3, Informative)
Windows stores the password as an (unencrypted) hex string in the registry.
Just to clarify...
Windows XP stores WiFi passwords unencrypted in registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WZCSVC\Parameters
Windows 6.x stores WiFi passwords in encrypted XML files under hard disk folder %PROGRAMDATA%\Microsoft\Wlansvc\Profiles\Interfaces
Re:KNetworkManager (Score:5, Informative)
Are you stupid? NetworkManager is the same underlying component. It will also store passwords in plain text for _system_ connections, where KWallet is unavailable (it is only available after graphical login).
This is a non-story. Every other operating system not only does exactly the same, they are forced to do the same. Because there is no other way unless you want your Wi-Fi to be offline until you login, and if you do, well, then this problem is not present because NetworkManager will use KWallet OR gnome-wallet, depending on the session you opened.
The author basically manually checked the "I want to make this connection available to other users" checkbox and then is surprised when the connection is actually made available to other users. Stupidity, plain and simple.
Only readable by root on my Debian Stable pc (Score:4, Informative)
Only readable by root on my Debian Stable workstation:
robert@debian:/etc/NetworkManager/system-connections$ ls -latr ..
total 16
drwxr-xr-x 5 root root 4096 May 20 2013
-rw------- 1 root root 329 May 21 2013 geophile.net
-rw------- 1 root root 399 Jul 4 13:22 Auto geophile.net
drwxr-xr-x 2 root root 4096 Jul 4 13:22 .
robert@debian:/etc/NetworkManager/system-connections$ cat geophile.net
cat: geophile.net: Permission denied
robert@debian:/etc/NetworkManager/system-connections$
Re:That's why Liux isn't 1st choice for security.. (Score:5, Informative)
If you want the system to use a wifi connection as its primary--to boot and enable wifi, or to allow all users to enable wifi--the wifi connection must store the password in plaintext.
Think like this: You get a wire, plug in an RJ-45, and tell the system to enable that on boot. When you boot, you're online.
Now, if you use wifi, to do this, you have two options. The first is for a user to log in, connect to wifi, and store the password encrypted in keyring. The next user logs in (after the first logs off, or after a reboot) and, not knowing the password, can't use the network on that machine. The second option is to store that password in plaintext, accessible by a system level service (or, alternately, by all users). At boot, the system service enables the network connection; any user with access rights to enable or disable the network connection can send a message to the service to do so, and the service will read the password from disk.
In the second scenario, if you create an encryption key and encrypt the password, you need to store the key in plaintext. An attacker would get the key and use it to decrypt the password in the same way as he'd obtain the plaintext password, so technically you are still storing plaintext--just in a different format involving multiple files. It's not encrypted until it's separated from the key. An encrypted e-mail is encrypted because only the sender and recipient have the key--the sender usually generates a session key and encrypts that with a public key, so usually no longer has the key after sending it. A third party would have an encrypted blob and no key. If you encrypted the e-mail and stored a private key to decrypt it on the same system, protected by a password stored in a text file on the same system, then administrative access gives you full access to everything--essentially, the message is stored in plaintext. That's a stretch; but if your system fundamentally functions such that it must store some data, and stores that data and an encryption key "to encrypt it", you're storing plaintext--the "encrypted" data is never transported, and the key is just theater.
So this isn't an example of poor security; it's an example of "the only way to accomplish this particular goal".
Re:And the problem is? (Score:2, Informative)
Re:Security - and a false sense of security (Score:2, Informative)
They are not encrypted. For that it would be necessary to use a user private key. Instead, they are obfuscated with a system key: http://securityxploded.com/wifi-password-secrets.php [securityxploded.com]
They are trivial to recover.
Re:Nothing changes... (Score:4, Informative)
Windows does the same thing. Does it automatically connect to Wifi when it boots?
We can store them in an exotic form of plaintext, like encrypted with the encryption key in /var, so you can use the encryption key to read the plaintext but we can claim it's "stored encrypted" even though this doesn't add security.
Re:What? (Score:5, Informative)
FiOS user here, and indeed they do not know.
When they brought and installed the router, they pointed out the password label, and I asked if the password could be changed, and they said yes. Sure enough, I changed it when they left, and changed the WEP to WPA2 as well via the router's "web" interface. The result is probably not secure (NSA aside), but GP and GGP are still worthy of Rep. Joe Wilson's attention [wikipedia.org].
The password can't be encrypted (Score:4, Informative)
The problem is that the system needs to be able to use the password to connect to the network, and it needs to do so without human intervention (because there may not be a human at the keyboard to enter a decryption password). So the password can't be stored encrypted in any meaningful way. If it is encrypted then the key or password to decrypt it must be stored in the clear so the system can use it, which is no different from storing the network password in the clear in the first place (any intruder that could get to the first could get to the second too). Better that the system not fool you into thinking that the password's stored more securely than it is.
The only way to change this is to change the system so that it doesn't connect to the network until after the user's logged in. That though would hose things that run without user intervention, since there's no guarantee that the user would've logged in between the time the system booted and the time the job ran (think automatic reboots, or reboots due to power failure). And since Unix doesn't have the concept of "the" single sole user, there's no guarantee that the user logging in is the one that knows the decryption password. And we won't even discuss systems where directories like /home needed for login are network shares and require the network to be available.
Re:PoetterKits (Score:3, Informative)
Re:KNetworkManager (Score:5, Informative)
It is not important that the directory /etc is not visible without root over a network connection! What is important is that most people who read this article will now claim that core Linux network managers are insecure,,,LOL
OF course if you enable remote access to any OS as root then all bets are off. You either make damn sure that whoever has access is trusted or you are stupid, Lets not cloud the article with inconvenient facts like network access to a box as root is not enabled by default and anyone who enables it by default unless they are absolutely stupid or the connection is encrypted and otherwise network secure deserves to get hosed.
Getting in the habit of not having to have root all the time is the strength of Linux and is why Windows sucks dead horse balls as an unprivileged user under Windows gets plastered with requests for the system password all the time. Whereas most Linux distros have software access privileges set in a sensible way WHICH DOES NOT INCLUDE THE ABILITY TO READ AND WRITE TO PLACES LIKE /usr /etc /var unless you are installing software and people who write software for Linux do not expect to write configurations anywhere except in the home user after an install. If someone writes a program which will send password data from /etc to a honeypot and that program is popular because it makes fart noises or plays poker on the net then as far as I am concerned the users got what the deserve. Same as Windows users that install garbage ware at the drop of a hat so that they can do something like play poker on the net from places like gamerareus.ru or happy_nice_pussgames.ru or bollywoodsy_games_freesongs.in ...as one of my friends seems to have a habit of doing so that he can play games on his WINDOWS laptop.
THIS WHOLE FREAKING ARTICLE IS MORE BULLSHIT AND FUD to amuse the crowd who come to slashdot to bash away at Linux most of whom do not even know wtf /etc is in the first place!
If a person that has root wants to enable a login by a passphrase at boot they can or with any linux distro they can choose to only enable network login after a user login EITHER WAY IS SECURE because the place where the passphrase is stored is invisible to the network, unless like I said remote login via root is enabled. Again it comes down to trust, you either trust the user or you do not plain and simple.
THE ONLY REASON YOU CAN TRUST OSS ON LINUX is because you can see the source and there is nowhere for malware to hide. Anyone that writes and compiles a binary for Linux then does not allow access to the source is on the same level of trust as those who write software for Windows. IT ALL COMES DOWN TO TRUST. Be very suspicious of any software for Linux that requires /root r+w after install. Gnome 2 network manager was flakey and thank heavens they fixed it in Gnome 3 the fact that it wrote network passphrases to a file in /etc was not a security issue unless someone wrote a piece of spyware to discover them and linux users were stupid enough to run it as root. Something which no one here seems to think has actually occurred. If someone argues this then point out the actual malware that Linux users were hosed by...eof and end of story.
Re: KNetworkManager (Score:3, Informative)
Storing it in the keychain is storing it as plaintext. There is _no_ way to store a secret in a secure way if it's to be used without user interaction or a TPM device.
Re:From a comment there (Score:3, Informative)
TPM is hated by Slashdot because the mobo manufacturers have a dirty habit of preloading the Microsoft keys and not allowing you any way to remove the Microsoft keys or use your own, effectively making it useless for any real security purpose (beyond vendor lock-in to Microsoft).
In fact, the ARM Windows RT tablets were required by Microsoft to force Microsoft's TPM SecureBoot keys only.
Microsoft's dirty tactics and motherboard manufacturers with their head in their ass are the reason TPM is shunned.
Re: KNetworkManager (Score:4, Informative)