Slashdot Mirror
Linux Distributions Storing Wi-Fi Passwords In Plain Text
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?"
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
Learning HOW to think is more important than learning WHAT to think.
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
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
Stop-Prism.org: Opt Out of Surveillance
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
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$
Uh, Linux geek since 1999.
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".
Support my political activism on Patreon.
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
They are trivial to recover.
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.
Support my political activism on Patreon.
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.
You can hold down the "B" button for continuous firing.
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.
Lennart Poettering has had nothing to do with NetworkManager: http://www.ohloh.net/p/network-manager/contributors
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.