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...
This is just another lead balloon for the project. Why not use a keyring? Why is it automatically set up to use multicast DNS by default? Why is it so damn hard to configure settings for a DHCP client?
Why is my networkmanager applet asking for access on kwallet?
i guess its only stored plaintext, if you want it to autoconnect globally. And then its required to be plaintext.
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.
It says they are stored under /etc/NetworkManager/system-connections
I have the info for my wired and wireless connections, but he passwords are definitely not stored in there plain-text or otherwise...
Which leads me to ask where does it store them?
"Encrypting the full disk"
Is that something I should be doing? New-ish Linux user here.
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'?
If the alternative is to put in a password for every fucking thing I do like KDE seems to insist then sure go ahead and steal my Wi-Fi password. In addition there must be more interesting stuff to take if access to my computer was compromised.
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
I've disabled the FIOS provided wireless access, added two wireless access points ( upstairs and downstairs ), each connected by hardwire to to the router and use whatever protocols and passwords I desire.
You don't need to have root access if you have physical access to the drive. Mount it, get the password, and then monitor the network activity of your target.
I am becoming gerund, destroyer of verbs.
OR more appropriately, wifi isn't 1st choice for security.
Change the perms so that only root can read them. If something has rooted your box, your wifi password is the least of your problems.
I want to delete my account but Slashdot doesn't allow it.
If the attacker is already root, they have access to everything on your system anyway.
Not quite. Root access means a compromised single host. Access to a list of WiFi passwords means compromising all the WiFi networks the machine in question has been given access to, so you'd still want that encrypted.
Insert
I've forgotten the WPA passphrases on two of my relatives wifi networks and of course since I set it up for them they never had a clue. Fortunately, the unencrypted networkmanager files were there and made it super easy for me to tell them what their passphrases were :)
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.
I would say it is FUD. If it is a company owned computer that is controlled by others, you might risk having your employer having access to your networks. Other than that the biggest risk is theft. If a computer is stolen, you should change all your passwords anyway, including your wireless network passwords. Friends and family that use it would have access to your network anyway. I'll admit to not RTFA, but it sounds like (I am speculating, I could be wrong) the author is parroting some stuff out of a security certification study guide without really considering if it is actually a problem worth writing about. It is possible the author is anti-linux, but I doubt it considering an alternative tools is suggested. If someone is really paranoid, they could always just use a live CD/thumb drive that doesn't store anything. I am leaning towards well meaning FUD.
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
Anyone who connects a GNU/Linux box via wireless network has no concern for security.
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.
The die hard Linux bunch will defend it to their deathbeds. If it was found that Windows was doing the same thing, they'd be lighting torches and sharpening the pitchforks. This is a serious security flaw. Not only does it expose passwords for people's home networks, but businesses and other institutions as well. I love Linux, use it on every laptop I have at home, which means there are several passwords stored on those machines. This is an issue that needs to be addressed and fixed. If disabling NetworkManager and enabling netctl accomplishes it, easy enough.
If the attacker has compromised that one system, they could just decrypt the encrypted file.
You do not have a moral or legal right to do absolutely anything you want.
The password encryption must be reversible to be used, is not the computer that runs linux the one that must do the validation so can have the luxury of doing one-way encryption, the original password must be provided. The source code already includes how to decrypt that password, and if is salted or uses another information, all the needed information is stored there already. At most, you can do what is already being done by most if not all network managers, only giving access to it to the root user. If someone else have access to your computer with root access and the ability to see files/run programs, then would be easy to obtain it even if is encrypted, but capturing your wifi password won't be the worst that will happen in that scenario.
I'm using WPA2 to discourage anyone trolling for the most easily abused access points, but if were transmitting my .secret_plans_to_rule_the_world file, I'd be using ipsec as well — to a machine which does not allow any unencrypted connections.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
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.
USER@DEBIAN73:/etc$ cat /etc/debian_version :/etc$ cat /etc/debian_version
7.3
USER@DEBIAN73:/etc$ sudo grep -R WPAKEY *
[sudo] password for USER:
7.3
USER@DEBIAN73:/etc$ sudo grep -R WPAKEY *
[sudo] password for USER:
NetworkManager/system-connections/ESSID:psk=WPAKEY
This is a bit embarassing...
Now, can somebody with the WPA key of a network capture traffic to/from other stations?
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...
They're (weak) access control features. Secure at the transport level.
All's true that is mistrusted
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.
That's not a good excuse. We could still make the damage smaller if he can't steal the WiFi password easily. Especially in a business network that can make an important difference.
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.
Cellphone reception is also terrible in the middle of my living room. My best bets are turning off Data on my cellphones so that it doesn't try to negotiate quicker speeds.
I'd really like to know how to improve things. House has been built last year. I expect this to be a common problem in low energy houses.
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
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?
I have steel beams between the first and second floors that seem to interfere with wifi. It could be something else, but since I have the two units and had hardwire between the floors, I use them.
Should it at least be hashed? Sure
I will as soon as I get home, but I have yet to verify if TFA is correct or just FUD for myself.
Normally passwords should be hashed, but in this case it would be pointless as hashing is used to compare. So I hash my password the first time then if I enter the same password each time its hash value will always be the same as the original, but once hashed the original password is "lost" in that it becomes unknown to the system. The problem is in order for your machine to automatically connect to an access point it needs the password. So either you type it in every time or you store it somewhere where the system can access it. Hashing is one way so if the system can only retrieve a hash of the password not the password itself so a hash can't be used to connect to an access point. You'd still have to enter your password every time or store it.
As others have pointed out you need root access to view the file, if someone has root access to your machine then you have bigger problems, so it doesn't matter if the password file is encrypted or not. If you wrote your password down and stored it in a bank vault and only the bank manager could retrieve it for you would it matter if people could still walk into the banks lobby? Maybe encrypting it would be a good extra step just in case, but I can't see it being a necessity.
Speaking of PSK security, you are using the mimimal PSK length of 20 (or was it 22?) characters to ensure security, right?
So you store the password in plain text, so what?
The password needs to be available in plain text form in order to be used, so even if you store it encrypted you must also store the key so that the system is able to retrieve it so at best all you do is make it slightly more difficult to extract the key.
For other systems there are freely available tools to extract the wifi keys anyway...
The only secure way to do it, is to encrypt the wifi key using the user's login password... MacOS can do this, but then your system won't connect to wireless until after you've logged in so this is a very uncommon configuration to use.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
As bad as it sounds, NetworkManager is probably doing almost the right thing. There is no way to safely encrypt a password so that it may be used for access to another system without requiring another password.The only thing that you can do is use the permission structure of the OS to protect the password. (As they have done)
Now, they could have "scrambled" or encrypted the password with a known key. That will prevent the slim chance that a "casual" intruder with root access will get your password, however, any moderately intent intruder who can gain root access will, by design, be able to reverse the password mutation. You can't MD5 or SHA the passwords because you *need* them to gain access to the external system.
I had this fight at a company a while back about accessing Windows servers and storing their credentials, I ended up base64 the creds into a database row or an encrypted database. You needed a password to open the database, so they were safe, but management didn't want to be able to "see" the password once they did. It wasn't real security, but it shut them up.
NetworkManager needs to do something similarly stupid so that stupid people don't say stupid things about a stupid problem. If you can't trust your computer to store your password, then don't trust your computer to store your password. duh!
I removed NetworkMangler from all my systems except my laptop. It does come in handy when connecting to WiFi hotspots when I'm not at home. Keeping it on a server with a static network connection is just inviting trouble.
Cheers,
Dave
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
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.
None of you know what you are talking about.
Only the State obtains its revenue by coercion. - Murray Rothbard
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.
I think the article is complaining that you do not have a choice. I think the counter-argument (that you need root so they own you anyway) is not legitimate. In this day and age, no passwords should be stored in plaintext.
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.
Then as root just install a key logger?
Either the WiFi password is decrypted with a user password (eg. local machine account log-in password), or the WiFi password is supplied directly by the user. No problem.
It's GNU/Linux dammit!
I have two access points as well. House is a two-story, 2,590 square feet. Cable access is at one end of the house and the main router is there as well. At the far end of the house, the signal has to go through several walls, a washer and dryer, and a staircase to get to the Chromecast plugged in behind the TV against the outer wall. It is about 1 bar and I am not about to try to use it like that as it will likely stutter and degrade. So I pulled wire to that end of the house and there is a second router (in simple bridge mode) there. As a bonus, I now have coverage in the upstairs master bedroom / bathroom where there was basically no signal before. BTW, this isn't a single router / brand issue. I have used about 7 or 8 different routers - all sorts of brands from Linksys, Netgear, Buffalo, etc. and they all had the same issue getting to the other end of the house.
A business network should be using per-user WiFi authentication (like WPA-Enterprise), already avoiding this problem.
one http://i.imgur.com/fZRHal3.png
two http://i.imgur.com/riiIbvX.png
Politics is Treachery, Religion is Brainwashing
Asking for the impossible does not help anyone. Publicizing the lack of response just makes you look like an ass. Particularly if you manage to go public on a forum full of technically knowledgeable people like Slashdot. (Yeah right).
Finally! A year of moderation! Ready for 2019?
(class B house)
Well there's your problem. You should be living in a class M environment.
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 article points to a deeper problem that exists with all unencrypted disks. What if the hardware gets into wrong hands? With encrypted disks you're never in urgency of changing all the passwords of bank cards, devices, online accounts stored on your system, in case the hardware is compromised. Encryption also protects your sensitive data to a great degree. I recommend all partitions to be made encrypted during the initial setup of the system.
I does even if you do encrypt them. Think!
If you are going to store the passwords in an encrypted format you need to have the key somewhere the user who owns the wifi passwords can read to decrypt them. In which case someone who has root can read the key and use it to decrypt the passwords.
You might make the key something like the users password itself, but that has implications too like what happens when the user changes their password. What happens if an alternative password change protocol has to be used because the user forgot their password and the sysadmin must do it? Does the user lose all the stored wireless passwords?
Generally speaking there isn't much in the way of something you know based schemes that will protect user data from the system administrator and provide single sign on. If you want to have some second password or token that acts as a cipher key for a password wallet that is one thing but there is a usability cost there, the use now has two passwords and if the wallet password is lost the data is probably lost.
Otherwise its a situation of root can read everyones files, which we knew, or some obfuscation that probably is more a false sense of security than anything. So pretty much the whole complaint is FUD.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
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?
SystemD has nothing to do with Gnome, apart from that some Gnome components use it.
Well we're talking about Linux here, not Windows, so Windows security problems aren't really relevant (though another post here says that Windows does essentially the same thing, storing WiFi passwords unencrypted in the registry).
But still, if someone on the internet hacks your system and gets your WiFi password, what good does that do them? They have to physically travel to your home to do anything with it. And even there, what is that going to gain them that they don't already have, since they've apparently hacked into your system?
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.
And here I thought that the main problem with NetworkManager is that it can't pick networks on priority, nor do roaming.
My phone also stores the wifi passwords (if it didn't also mail them to google). If someone gets root access on my machine, I'll just change my wifi passwords. I don't really see the problem - if someone gets root access on my *other* machines, they are already connected to my LAN, which doesn't require a password.
Aha: the 5GHz thing might be your problem. 5GHz has poorer range and is more attenuated by walls than 2.4GHz. I'm only using 2.4, so I'm not seeing these problems.
How come the only class with a name is Minshara?
I guess all UNIX's are Class Y (Demon worlds)
I can't comment on whether NetworkManager stores Wi-Fi passwords in plain text, but I do have some very painful experience with NM in RHEL 6 and I strongly, strongly encourage everyone to avoid using NM. It's buggy and works very, very poorly.
Circle the wagons and fire inward. Entropy increases without bounds.
Trust a WAP to bring theory to a practical fight.
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.
Hashing it would make it unusable... Unless your using an authentication scheme like NTLM, where you simply make the hash the equivalent of plaintext anyway - eliminating any benefits from hashing it.
You could encrypt it, but then every time you wanted to connect you would need a copy of the decryption key. Either you store the decryption key on the system itself, in which case anyone has root or physical access needs only to work out how to extract the key, or you require that the key be entered every time - in which case you might as well not store the wifi key at all and simply require the user to re-enter that every time instead.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
...so you're saying Linux needs something like the OS X Keychain?
Well, is it not the same people that were behind the changes in Gnome 3 so everything over to tablet mode, udev, and advocating the use of binary configuration files?
Crimey
Lennart Poettering has had nothing to do with NetworkManager: http://www.ohloh.net/p/network-manager/contributors
We're talking about operating systems and how they handle security, so I don't think the Windows example is completely out-of-place.
What if your Wifi password is the same password you use everywhere? I know that's a dumb move, but you'd be surprised how many people suck at using different passwords for each login. Security is like an onion, it's comprised of layers. If you take away one of those layers, you increase the likelihood of an attack.
Crimey
If he wants, he can:
$ nmcli
Usage: nmcli [OPTIONS] OBJECT { COMMAND | help }
OPTIONS
(snip because of lameness filter)
Don't fight for your country, if your country does not fight for you.
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.
Not exactly. wpa_supplicant and most tools that use it store an intermediate hash of the password, since the password is hashed as a step in the process of logging into WPAx-PSK (which everyone is using WPA by now, right? Right?). This isn't perfect, since the hash is still secret and you can just copy the hash to another computer to log in with wpa_supplicant, but good luck figuring out what the plaintext password used to be in order to punch it into some gooey dialog box. Some WPA-EAP variants (generally using CHAP compatible handshakes) can do the same by storing an NT hash.
See also http://unix.stackexchange.com/questions/74500/wpa-supplicant-store-password-as-hash-wpa-eap-with-phase2-auth-pap
If I have been able to see further than others, it is because I bought a pair of binoculars.
That's the *only* vague use for it. If you're wired, there's absolutely no need for it. On CentOS/RHEL/Scientific Linux, service network start will do perfectly well.
mark
Except with it stored unecrypted they don't NEED physical access, they merely need you to follow a few simple instructions [geekzone.co.nz] and download their "free codec" or similar trick.
Ditto if you store it encrypted so what's the point?
Oh dears.... if my machine is compromised it can spill my SSID and the password to get there and then the big bad man outside my door can surf child prons and communicate with Al Qaeda and access my completely unsecured internal network 'cause I don't know how to turn my public sharing off on my Windoze machines and...............
If someone has compromised my system and gotten to my WiFi password I've got much deeper shit going on with my system to be worried about.
FUD, plain and simple.
Depends on the system. Maybe the user is supposed to have root or physical access to system X, but not access to wifi access point Y from system Z.
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.
The problem with that logic is that the key can be obtained using the exact same trick (fool the user to run your application) since a shared key can only be obfuscated and not truly encrypted.
There are two alternative designs that are slightly more secure.
First, usually the WiFi password file is globally-readable. It really only needs to be root-readable, though this makes the network management architecture a little more complicated.
Second, you can use user-specific WiFi connections, where the password is stored in a database encrypted using the user's login password and decrypted at login time.
I remember someone saying that MS does not store the PSK, but stores the PMK. Assuming neither NIC gets changed, that should be enough. Note: I have not had an opportunity to check this.
I'm pretty sure they were all Vulcan names that humans couldn't universally pronounce correctly, so they dumbed them down to just the letter.
# cd /etc/sysconfig/network-scripts
# ls keys-*
keys-HACKUS
# cat keys-HACKUS
WPA_PSK='HACKUSISCOOL'
http://www.youtube.com/watch?v=6nSKkwzwdW4 :-)
-Hackus
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
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
There's your problem. At least you didn't include the word just. If anyone ever tells me "it should just work", I know it's broken.
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.
I'm replying with my account because the slashdot beta doesn't seem to let me link to a post directly, so I can't just remember where I laid replies as an Anonymous Coward.
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.
Oh you wanted your VPN? Not going into that (too many flavors), but if NetworkManager can do it, so can you with a little research. BONUS: Instead of outright connecting to your workplace, if you manage your VPN manually you can decide what traffic gets routed through your employer's network (think B2B VPN configuration, check with your neighborhood SysAdmin to be sure you're not violating network security policies). Finally - a way to keep wrok and pron separate!
Full disk encryption does one thing: adds another password layer.
The whole idea of it being a solution to the problem is bullshit.
Actually in some moist delicious irony Windows does NOT store the WiFi unencrypted, the last one that did was WinXP which was depreciated and is all but abandoned by MSFT, the rest? Store it in an encrypted XML file which the system and NOT the user has the keys for so the only way for them to get it would be to somehow corrupt the WiFi password file AND disconnect the session so the user would be forced to re-input the password while they were monitoring.
And it is very MUCH relevant as I was attempting to point out that a good 9 times out of 10 the weakest link is NOT the operating system, its the user. Apparently you didn't follow the narrative for whatever reason, so I will elaborate. See this how to write a Linux virus in 5 easy steps page? It works the exact same way that pretty much every current bit of malware on Windows, from the "free porn codec" to the security tool and FBI porn bug variants work and that is by fooling the user in order to get them help the malware writer past the defenses.
Go look at the top 10, hell the top 50 malware infections and guess what? They ALL work the same way, get the user to help lower the defenses. All TFA shows is that once a malware writer gets a Linux user to lower the defenses the system will be that much trivial to pwn, that's all. But at the end of the day the vaunted "Linux security" is worth a bucket of piss against the top 20 malware writers because they all know where the weakest link in the security chain, as those million Android infections show Linux security PEBKAC.
ACs don't waste your time replying, your posts are never seen by me.
When it gets to the point of talking about stolen hardware there is one single thing that people seem to forget: the hardware is probably worth a lot more to the thief than your data. They're more likely to wipe it and resell it unless they were there for your identity to begin with, and for that there are plenty of more reasonable angles of attack.
the last one that did was WinXP which was depreciated
Sorry, you can't depreciate WinXP on your tax forms.
As for your article, it's mostly right, but the problem with malware on Linux (not Android) is that there's too much diversity. One of the comments after that article said it best:
Unlike other platforms, with Linux, users could be running several different things. This is more true today than in 2009, when this article was written. Back then, there were only KDE and Gnome2, with others having very little usage. Now, there's KDE, Gnome3, Unity, MATE, Cinnamon, XFCE, and several others (most of this caused by the Unity and Gnome3 dual debacles, forcing people to flee to or create new alternatives). On top of that, there's different distros. So something that might work on one may not work on another. The article's author even mentioned Thunar (the XFCE file manager), as it flags desktop launchers as potential malware; there's nothing stopping other file managers from doing the same thing, and who knows, maybe some do by now.
Android is a little different since there's only one Android (though it does get some different "skins" from the handset makers, like TouchWiz and HTC Sense) (though it does have a few different versions, not different from Windows with its XP, Vista, 7, and 8). It also has a huge marketshare in mobile phones, unlike desktop Linux which has a rather small marketshare (as best as anyone can tell, since there's no reliable way to count Linux users since it's usually installed after-the-fact, unlike Windows/MacOS). It really isn't worth it for a malware writer to target Linux and hope they get one of the less-savvy users (grandma whose grandson set up her computer with Ubuntu because he was sick of getting called over to fix her Windows computer so often) when they can target the Big Two instead.
1. NetworkManager can do both
2. Passwords are _always_ stored with reversible encryption algorithm
3. Solution: KDE uses kwallet and f*cks my brain every time i want to connect to my wifi
"It feels like I'm at the Zoo when reading this thread - I'm frightened, but it's interesting" (c)
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.
NetworkManager and its frontends for Gnome, KDE and other desktops should be improved in a way that the data is stored in database which should be encrypted and only be accessible through a local service for those users who own the keys.
Basically, you first make sure your wi-fi password is not shared with any of your other passwords, and second you make sure you don't allow any fool on your wi-fi access to anything without additional credentials. So then the worst that happens is that someone gets free internet off of you until you tighten up your linux distro security (they fact that they are reading plain text files on your private computer is cause for enough concern already).
Yup, I had to figure out wi-fi password on my mother's computer by browsing the registry (get the big long ugly password instead of the short one, but it worked).
On the other hand, I don't want my computer doing anything when I'm not on it. Which is why I shut it off every night. At work I shut off wi-fi completely on the laptop, it's pointless and slower than ethernet.
But you crack the password manager once and you've got access to everything. I don't trust the Mac's keychain so I keep passwords either in my head or the vital passwords on an external thumb drive I keep with me. The keychain would only be for non vital stuff, like forum passwords.
Opensuse 13.1, did 'grep [first four letters of my Wi-Fi password] /etc/ -R'. No results. FUD?
A stack of wrappers is what unix/Linux strives for, its nothing new. At the bottom will be a binary blob, at least for any modern chipset. Unfortunately that's not likely to change any time soon.
Sig Battery depleted. Reverting to safe mode.
Because the answer is "No, it is not possible" for WPA-EAP-PAP, specifically. Read the rest of the question and answer. PAP falls under "some other WPA-EAP variants" in my post.
If I have been able to see further than others, it is because I bought a pair of binoculars.
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.
To answer my own question here's what OS X and Windows do with system wide wifi passwords:
OS X stores the wifi password in the (encrypted) System keychain. The System keychain (System.keychain) is stored in a known location on disk and the material to decrypt it (SystemKey) is also stored in a known location on disk. The permissions on SystemKey file are set to be readable by only root.
What Windows does varies depending on version. For XP the wifi password is converted into a key and this key is stored directly in the registry unencrypted. For Vista and later the wifi password is encrypted (not turned into a key) with the System's Master Key and saved into XML file inside a known path on disk. To reverse this process offline, you need the particular decrypted Master Key used to encrypt the wifi password. Due to the way that Window's DPAPI works there may be many multiple Master Key's, one of which was the one actually used to encrypt the wifi password. All System Master Key's live under a well known path on disk but are encrypted. To decrypt a System Master Key, data from the SYSTEM and SECURITY registry hives has to be used. Permissions on the aforementioned registry hives and Master Keys is tight so even a "regular" Administrator cannot directly access the underlying files while the system is running and some of the files are marked as hidden (but this is by the by for an offline attack).
Unless your boot is "Please enter password to boot up computer" before it can boot the OS.
Of course it is. Any other FDE is the sprinkling of magic encryption dust kind of FDE. Both initscripts (on RH-style systems) and systemd support this, and have for years.
Oh, and that still doesn't answer why laptops are trickier than desktops in this regard.
Depends on what your floors are made of. If it is made of concrete the signal is blocked. If you live in a concrete house you often can't even use a cell phone without going to a window and you may need repeaters for wifi in each room unless you can place it in a hall where the signal can reach the rooms through the doors. Concrete is common in modern urban appartments but less so in suburban single home houses.
No, he brought an anecdote. The theory is sound. Wifi can not penetrate concrete.
Not a real problem.
By default there is no read permission except
by root.
Not a real problem...
A stranger must own your machine to grab the phrase.
Not a real problem.
Knowing the key to a WiFi link that travels less than
100 feet in most cases has no value unless your snooping
device is also within 100 feet.
Not a real problem.
Data coming off the WiFi router is not encrypted on links
that can be snooped on half a continent away.
Not a real problem.
If you care, establish a VPN link between you
and some place you trust.
Not a real problem. ... In a family of six the pass phrase needs to
If the key was encrypted
be shares with at least six. Add the babysitter and key management in
a home gets to be so much trouble that silly user tricks will make it
worse.
Truth is stranger than fiction, but it is because Fiction is obliged to stick to possibilities; Truth isn't. Mark Twain.
NM is a real pain in the ass.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
I think we can all agree that there is nothing approaching a secure and universally acceptable way to handle this problem.
My first opinion is that for the majority of users, our laptops or desktops are personal systems in a non hostile internal environment. If we encrypt the network passwords, a decision would be to decide if a specific group (user) is the owner, and if all the other users are member of that group.
That way, I could, if encryption became the defacto standard, allow all my enrolled users network access.
OK, what about hacker programs which somehow are now behind the scenes with privileges. All they need do is join the appropriate group, which would entitle them to network access. (dont want to use a group, use a privileges list via selinux or other means.
As this security has little to do with the router security, I deep the network passwords a FUD argument.
Leslie Satenstein Montreal Quebec Canada
No, he brought an anecdote. The theory is sound. Wifi can not penetrate the rebar in concrete.
FTFY
The rebar should not matter much, it has too big holes to stop WiFi frequencies. It's just signal getting weaker when passing through the material. Rebar certainly plays a part in that, but does not stop the signal.