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?"
Must have been the NSA! I should have known that commit from uberspydude@ftmeade-totallynotNSA.gov was suspicious.
AntiFA: An abbreviation for Anti First Amendment.
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.
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.
It's anti-Linux [...] -Stallman fan
Fraudster! You didn't put GNU/Linux.
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...
And thats not the worst part. You can't change your PW, and they only offer WEP.
Since when does being a Socialist mean 'someone who has a different opinion than me'?
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
OR more appropriately, wifi isn't 1st choice for security.
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
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I suppose in general that keeping "secret" things secret seems reasonable. After all, when you login to your wifi network (the first time) the password is usually masked to hide it from shoulder surfers. This does give users the impression that the data is also stored securely.
From a practical perspective, though, how much of a security risk is this?
From TFA:
So anyone who inserts a Live CD Linux distro into your laptop, can view your not-so-secret Wi-Fi password... or steal even more important data!
Wouldn't it be even easier if someone had access to your laptop to just use it then and there to access your network without rebooting, "stealing" your important data secured by nothing more than a wifi login? They're already in your home or office -- unless they stole your laptop while you were in the restroom at Starbucks -- they could also just plug their own laptop into your router or other network port and get the same thing, couldn't they? (As if your "sensitive documents" aren't just sitting there on the laptop unencrypted anyway.) Or just hang around in network range, sniffing packets and cracking your wifi encryption at their leisure? That wouldn't even require taking the risk of borrowing your computer and raising suspicioins.
So while storing any authentication data in plain text seems needlessly insecure and sloppy, relying on wifi passwords alone to protect sensitive data is an even worse idea to begin with.
I am not a crackpot.
Well, and it's NetworkManager. Nothing of value is lost by uninstalling it to begin with.
Support the EFF and Creative Commons. The war is coming, and they're supporting you...
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.
Sure, but if you're root, then you can quite easily decrypt to find those passwords. This isn't to say that it shouldn't be encrypted (another hurdle, etc), but once you're root, then anything on that machine is fair game, including those WiFi passwords if you're determined enough.
Dunno what the original poster has but I have a 1600 sq foot house. basement first floor and second floor. 795 sqft rectangular foot print. My wifi access point on the first floor gets a horrid signal in the basement (especially near the corners). My wifi router in the basement doesn't reach the top floor corners.
This is specific to the 5ghz bandwidth which I use exclusively.
Yes, custom antennas might help, but wifi routers are cheap (just for reference I have an Asus rt-n56u and a buffalo wzr-hp-ag300h).
House is built in 1946. There are many situations where a single wifi access point doesn't work, even when you'd think it might.
The reality is far, far worse. Even as a non-root user, if I click on the wireless connection icon on my desktop, select my network under Edit Connections, and click "Show Password", there it is, in pure plaintext!
Oh, NOES! If my desktop lets me have access to my own network password, where will it end? It might even let me access my own files! Then what? Human sacrifice, dogs and cats living together... mass hysteria!
Why do you have two APs? WiFi penetrates to adjacent floors on a typical residential home with no trouble. I have a 3-story (including the basement) house with my AP on the middle floor, and I have no connectivity problems at all. The problem with WiFi is line-of-sight distance; if your house is a giant 6000sf McMansion and is really spread out, you could have a problem, but as long as you're not far away from the AP it should be fine.
Sorry, you brought theory to a practical fight.
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.
I have two APs.
One for 2.4 GHz b/g/n devices that can't really be upgraded. Older phones, Chromebooks, tablets and my bathroom scale.
The other is for 2.4 GHz/5 GHz 802.11ac devices that HAVE been upgraded and use the extra bandwidth, like for streaming HD video or transferring large files to a server.
I keep them on separate channels.
Learning HOW to think is more important than learning WHAT to think.
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?
That 'encrypted' key is no such thing. The passphrase you enter is used as input to a key-derivation algorithm. The value stored by netctl is the output of that algorithm. The interesting thing is that you can use that passphrase *as* the password too. So netctl is no more secure than NetworkManager storing it in a file on disk. The only thing it protects is someone knowing that the passphrase is BatteryHorseStaple - it doesn't protect your network at all.
The configuration file's permissions are sufficient to hide it from other users but not from physical access, as TFA notes you can encrypt your disk to protect that.
Or use a keyring, which NetworkManager does support. That will store it truly encrypted. The configuration files are just a simple fallback mechanism for when that isn't available.
No passwords stored as plaintext on my system's disk. Only on the yellow post-it stuck to the display.
Have gnu, will travel.
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.
As an admin, there are plenty of ways I can, if I choose, keep my data from being viewable by my fellow admins.
Yes, it takes a bit of extra work, but it's entirely doable.....
The issue of passwords being stored unencrypted on media has come up before with Android email passwords, Pidgin passwords and so on. If your attacker can bypass filesystem permissions you are already in a world of pain. One way to mitigate this would be to use a password protected keychain/keyring but this only works if you don't automatically unlock it...
Say that I want my Windows machine to automatically log in as a user when I turn it on. Because of the way Windows works it needs to be able to unlock my account (almost certainly to be able to unlock credential stores that would be otherwise locked), which means that when I enable Windows auto-login my password is going to be saved into the registry in plain text.
Perhaps Mac OS X can magically do better? Well not really - OS X XOR's your password with a fixed key and saves into /etc/kcpassword. For an attacker this is not a big hurdle over what Windows does. Unless your password is available OS X would be unable to unlock your keychain and all sorts of things would have to start prompting you if they wished to work.
If the keys to reverse the encryption are stored alongside the encrypted object you have not gained any more security but are just obfuscating your data - an attacker can simply steal both at the same time, run the decryption algorithm and use the object. To be secure you need to have something your attacker doesn't have access to which is at odds with unattended operation. If you want to have something happen completely unattended (i.e. from power on) fashion you are going to need ALL the information available in a directly usable form at some point and it's going to have to be "unprotected". While saving things like hashes are bit better (as they don't reveal the underlying password which may have been reused elsewhere) someone can still steal the hash and use it as is for accessing that service and in many cases a hash is no good as challenge response is being used to prevent the whole secret from having to be passed.
I do have one question though - what do OS X and Windows when you save things like WiFi/802.11x passwords that are accessible to every user? To what extent do they try and protect their system "keychains" and wouldn't such protection be obfuscation?
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.
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.
...so you're saying Linux needs something like the OS X Keychain?
Lennart Poettering has had nothing to do with NetworkManager: http://www.ohloh.net/p/network-manager/contributors
No, that's exactly what I'm saying it should [b]not[/b[ have. Credentials should never ever be read except exactly when they're needed, nor cached, and applications that use them should not have write access.
A plain text file is fine, but a process with escalated privileges that reads and writes to it is not.
Really the main problem I have with NetWorkManager on a surface UI level is that nobody seemed to deem it necessary to smooth out the case for people who just want to type their password in and NOT have it stored persistantly, just cached until reboot or (optionally) logout from the window manager. If you do not store your creds, it constantly asks you for them whenever it re-attaches to an SSID. Not only that but it stacks up multiple popup windows while you are AFK until your OS is lagging and your taskbar looks like a zip-tie. When you're validating an EAP cert there is NO REASON to do this EVER -- if you are presented with a validated cert from your home AAA server, re-using the creds shiuld be the default behavior.
The other major problem we have with Linux and Android's WiFi, both with and without NM, is that there are certain types of disassociation events after which the machine should run another DHCP transaction, and it doesn't. Wreaks havoc with dynamic authorization scenarios such as registration portals.
There is a use-case for utilities like NM -- wpa-supplicant and dhcpd and UI configuration utilities need to be glued together somehow, and if you have ipsec tunnels and l2tp running there is even more to be pasted together. NM does a poor job of it, but at least it does do the job.
Someone had to do it.
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.
Nope, American. I live in the northeast in a 1930-vintage wood-frame house, and my AP is 2.4GHz. I hadn't considered 5GHz or steel beams when I wrote that, which apparently are some significant factors for some people. Not much stucco around here, thankfully (that shit looks horrible), and the houses here all tend to be similar to this one: fairly old and all-wood. The kitchen here is at the opposite end of the house from where my AP is located, so the kitchen appliances aren't really a factor, though I don't notice any problems when I use my laptop in there either. The water heater and boiler are in the basement, so they don't block any places.
What is your threat model?
In short, in order to decide what security you need, you must first formulate your threat model. For a funny take on this see XKCD.