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?"
NSA DID IT! (Score:5, Funny)
Must have been the NSA! I should have known that commit from uberspydude@ftmeade-totallynotNSA.gov was suspicious.
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]
Re: (Score:3, Funny)
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.
Re:KNetworkManager (Score:5, Interesting)
Well actually, you can stash the password in a system-level store, like a keychain, so it's not in plaintext. AFAIK that's what mac os x does.
They don't have to use plaintext - they could use, say, blowfish. Sure they key would have to be stored somewhere. But anything that isn't plaintext is more work to crack. It's substantially more work to dig a key out of a system and decrypt something than it is to do a
cat pasword_file
As someone once said, security is about layers. Sure the password will be unencrypted in RAM - but you don't have to make it easy for people to get it. Is WEP better than no encryption? Sure - the extra 10 minutes may dissuade someone and they'll move on. Plus breaking the encryption means intent, which may be useful if there ever was a court case stemming from the activity.
There's a big difference between "yeah, i broke the encryption, it was so easy" and "I just sort of stumbled on this network."
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: KNetworkManager (Score:4, Informative)
Re: KNetworkManager (Score:4, Interesting)
Obfuscation provides no security, it just looks like it does.
If the operating system needs to perform a series of steps to turn the encrypted password back into plain text so can an attacker.
Re: KNetworkManager (Score:4, Insightful)
Re:KNetworkManager (Score:5, Interesting)
I mostly agree, especially about it being a non-story.
Part of the issue, I think, is conflating a wifi password with other passwords. A wifi password has several properties that set it apart from others.
For one thing, it is usually shared between devices, even ones used by different people (lets ignore advanced schemes, if you are setting up some manner of authentication none of this applies).
Secondly, it is only useful within a small geographic location. A website or email password can be used by someone half the world away. A wifi password is only useful within range of your particular access point.
Thirdly, the exposure is mostly limited. While its true that someone could drive up to your AP and start transmitting child porn, and that could lead to some serious consequences; the real abuses here are only attractive to a limited audience and not something generally useful or generally financially useful.... it doesn't give them access to your accounts, even your email downloads are likely encrypted to him.
Overall, exploiting this is more work than it is worth much of the time, and if it wasn't, it isn't like it is impossible to add more controls. If you really are paranoid, you can always drop wifi devices onto their own segment that can only talk to a VPN endpoint....shit then you can run the wifi passwordless and use the VPN for protection.
In any case, this is 99.9% a non-issue.
Re: (Score:3)
NetworkManager was originally developed by Red Hat and now is hosted by the GNOME project.
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.
From a comment there (Score:5, Insightful)
While it is true that the passwords are stored as plain text, in order to view the "plain text" one must have root privileges to view the text file.
I would venture to state that "if" one's system is open enough (a stranger has root privileges) for some unwanted person to view that text file, then one has much more to worry about than the fact that one's wifi password is not encrypted.
Also, to fix it, one must disable the "Available to All Users" option... thus requiring one to enter one's password for wifi on every login... which is annoying to say the least.
Personally, I think the issue is pretty much a mountain out of a molehill... because, and again, if to view it, you have to be root, then the whole system is vulnerable and not just the wifi password.
Which completely ignores security vulnerabilities in Linux, as many advocates do. Still, the relevant point is that for someone to steal your wifi password this way, they're already in position to do much worse.
Re:From a comment there (Score:4, Insightful)
Re: (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:From a comment there (Score:5, Insightful)
No, it does not. Have you actually read the part "" one's system is open enough (a stranger has root privileges) for some unwanted person to view that text file, then one has much more to worry about than the fact that one's wifi password is not encrypted."? Apparently not. As the password has to be available in plain at the authentication time, this nicely sums up, why the password storage is not a problem. But to understand that, you would actually need to have a minimal clue what you are talking about...
Re: (Score:2)
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.
This ignores multiuser systems.
Simply having an account on a multiuser system does not mean I want all admins on that system to have access to my info.
Worse than that, if you accept that argument as valid, then there is no point in encrypting and/or hashing passwords. Ever. Just store the file in a "safe" place.
Re:From a comment there (Score:5, Interesting)
You cannot hash wifi passwords. The password needs to be available in plain text form at authentication time. Root can always get to the unencrypted bits, no matter which weird obscuration mechanism you try to use. Even if you require the user to type in an unlock key every time, root can sniff the key.
Mandatory access control like SELinux or AppArmor can actually provide some security in this case. Sprinkling magic encryption dust cannot.
Re:From a comment there (Score:4, Insightful)
This.
This comes up all the time, and people are always shocked and horrified that certain data are stored in plain text. They want instead for magic encryption dust to be sprinkled on things. But often it's the case that there is no reasonable alternative. Data like WiFi passwords have to be available in plain text at the time they are used. If your system is configured so that a WiFi connection should be available to any user (or if it should be connected at boot time, before user login), then it must be available in plain text. If you encrypt it, the same party that would have had access to the plain-text form instead needs access to the encryption key, which means that the encryption is doing nothing.
There are some design failures that could be improved. User-specific WiFi connections can have their passwords encrypted, but they are often not as well-supported or well-designed as they should be. User-specific networking configuration in general under Linux is not very well supported (to be fair, it's tricky), but it's a good option for any really multi-user system.
Encrypting the whole disk is certainly an option, as the article points out, but it's solving a different problem. There's tons of plaintext data that your system needs to have access to that's potentially sensitive. That's the nature of the system. You can't realistically encrypt it from the perspective of the "live" system -- the live system would just need the encryption key, too -- but you can encrypt the disk, which encrypts it from an attacker that has access to the powered-off hardware. However, a) this is a much broader protection than solving "WiFi passwords aren't encrypted", b) if an attacker has access to your hardware, realistically, WiFi passwords are the least of your concerns, and c) full-disk encryption can be tricky to do right on laptops, which are the main user of WiFi.
Re: (Score:3)
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.....
Security - and a false sense of security (Score:2, Insightful)
The OS has to be able to decrypt the password to connect to the wifi network.
Windows stores the password as an (unencrypted) hex string in the registry. Guess I've gotta go with full-disk encryption then...
Re: (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: (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: (Score:2)
From your link:
One catch here is that you can't just decrypt the password even though you are administrator. To successfully decrypt the password, you have to perform the decryption operation under system context.
There are many ways to execute the code under SYSTEM context, one of the popular way is to inject the code via remote thread [Reference 2] in system process - LSASS.EXE. But this one is more risky, as any flaw in code can bring down the entire system. Much safer way is to create Windows service as System account and then execute the above decryption code from that service.
How would encrypting it with a user key help?
Re: (Score:3)
What exactly does it help that they are encrypted? The system can obviously decrypt them, otherwise it would not be able to use the passwords at all. Therefore the encryption is just obscuration, and it might lead people to apply insufficient protection to the files themselves in the belief that the contents are not sensitive.
So? (Score:2)
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.
Alternative? (Score:2)
Re: (Score:2)
In KDE the Wallet acts as a central keyring for all your passwords. You only have to enter the password for the Wallet the first time something needs access and it'll handle it from there.
The first time a program tries to access the Wallet you'll get a "allow / disallow" prompt, but that is it.
If you're bitching about having to enter a password ONCE after logging in then you don't even belong in the discussion.
Re:Alternative? (Score:4, Insightful)
If you're bitching about having to enter a password ONCE after logging in then you don't even belong in the discussion.
Slightly off-topic, but - If I entered a password to log in, why do I need to enter another?
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
Re: (Score:2)
Has to be readable yes. Has to be plain text? No.
If I give you something encrypted with OpesnSSL and a password, you can break it right? After all, you know everything that OpenSSL does. The wifi password, and any other external credential, should be protected at rest. And yes, it can be done securely even with full source access.
Re: (Score:2, Informative)
man chmod (Score:2)
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.
This has saved my butt a couple of times :) (Score:2)
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 :)
Re: (Score:2)
Whenever I set up a network for friends/family/etc, I get a piece of white* electrical tape, and write on it the SSID and passphrase. I usually also suggest that they put this information on the refrigerator, so that if guests come over, they can readily get online.
Later, when they ask me how to set up their new tablet, I say "go find the router... the information is all written on it."
I usually get a second piece of tape and write login username and password on it, and stick that on the bottom.
At the poin
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.
Re: (Score:2)
I hate it when people say reversible encryption is "pointless". There are a few reason where you might want to let someone look at your configuration file/database/etc (maybe to ask for help), and having to sanitize/restore passwords every time is a pain in the ass. You might also open the file while someone is sitting next to you, forgetting that the password is in plaintext. Most people are honest but if the password is staring them straight in the face it becomes a tempting target.
It's like saying bec
Re: (Score:2, Funny)
Re: (Score:2)
Yea, typical incompetent IT security wannabe. Pathetic, but all too common.
Re: (Score:2)
I hate people that do not read what I wrote. Incidentally, I could not care less what you hate, especially when it has no relation to what I just wrote.
Your rant is completely unrelated to the problem at hand, and if "the password is staring them straight in the face" they already have root access here and can do whatever they want, including things like starting WiFi automatically. So, no, encryption passwords is not always pointless, but it is almost always the wrong solution, and it very much is here. Yo
Re: (Score:2)
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?
By an agent, like KNetworkManager, PGP-agent or GnuPG-agent.
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).
No. An additional password isn't pointless. It is the purpose behind the operation of gpg-agent, KNetworkManager, Firefox's master password, LastPass and several other programs.
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.
To be pedantic, that is exactly how WPA2-Enterprise works. But almost no one uses that in a home network. You still shouldn't ignore it.
And the password does not need to be STORED in plaintext, which is the point. Like a PGP key, it exists unencrypted only in RAM and is encr
Re: (Score:3)
An attacker with physical access can defeat any obfuscation scheme that doesn't require input from the user.
The point of having a wireless key stored in plaintext (or obfuscated) is so that the computer can connect to that network without input from the user.
Encrypting the key requires input from the user, so storing the key is effectively pointless. Obfuscating the key doesn't actually do anything to stop anyone with root access. Whatever choice you make you wil
Re: (Score:2)
It is pointless for the situation at hand. You are ignoring the work-flow here. Compare both for a typical situation.
FUD (Score:2)
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.
Reversible encryption (Score:2)
You're not still counting on WPA2? (Score:2)
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.
Physical access gets wifi access. Okay. (Score:3)
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.
Wi-Fi passwords are not security features (Score:2)
Re: (Score:2)
It's FAR worse than that! (Score:3)
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!
You need the plaintext password (Score:2)
Speaking of PSK security, you are using the mimimal PSK length of 20 (or was it 22?) characters to ensure
So what? (Score:2)
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 you
Stored Credentials are bad (Score:2)
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,
NetworkMangler (Score:2)
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
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$
netctl doesn't encrypt it either (Score:3)
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.
Nope. I'm OK. (Score:5, Funny)
No passwords stored as plaintext on my system's disk. Only on the yellow post-it stuck to the display.
only root can read it in Wicd (Score:2)
two http://i.imgur.com/riiIbvX.png [imgur.com]
Passwords and automation (Score:4, Interesting)
The issue of passwords being stored unencrypted on media has come up before with Android email passwords [slashdot.org], Pidgin passwords [pidgin.im] 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 [microsoft.com].
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 [brock-family.org]. 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 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:FUD (Score:5, Funny)
It's anti-Linux [...] -Stallman fan
Fraudster! You didn't put GNU/Linux.
Re: (Score:3, Informative)
Re: (Score:3, Insightful)
NetworkManager doesn't follow the Unix philosophy, and was made by and for a younger point-and-drool generation grown up with kitchen sink apps with camel case names and MSDOS configuration files.
In short, it is an atrocity that does not belong.
As for storing the password in plaintext, it should not store it at all. The admin should store the credentials, not the app. In a file with read access for only the app that needs it, and no gratuitous root privileges when not needed. This dumbing down to make it
Re:FUD (Score:4, Interesting)
...so you're saying Linux needs something like the OS X Keychain [wikipedia.org]?
Re: (Score:3)
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.
Re:FUD (Score:5, Insightful)
Then you don't regularly communicate with remote git, Subversion, CVS, FTP SFTP, FTPS, or HTTPS websites with passwords. Even SSH and SSL key management is vastly improved by having some kind of graceful keychain to unlock, and release, keys as needed. The command line tools are too awkward, even for me, to consistently handle them across a wide range of application I might use in a day.
Re:FUD (Score:4, Interesting)
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.
Re: (Score:3)
What? (Score:2)
None of you know what you are talking about.
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].
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:3)
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
Re: (Score:2)
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.
Re: (Score:3, Funny)
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.
Re: (Score:3)
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.
Re: (Score:2)
Re: (Score:2, Funny)
(class B house)
Well there's your problem. You should be living in a class M environment.
Re: (Score:3)
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
Re: (Score:2)
A lot of distributions offer LUKS encryption on bootup. I'd highly recommend going that route.
As for storing a Wi-Fi key plaintext, I consider it a nonissue because any program that gets root will be able to get the Wi-Fi password anyway, and even if it is obfuscated, there will always have to be a way to de-obfuscate it.
Re: (Score:2)
Usually, no (Score:3)
What is your threat model?
Re: (Score:2)
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.
Re:It's true -- but only root can read them though (Score:5, Insightful)
If someone has physical access to your drive, you have much, much worse problems than someone sniffing your WiFi traffic. To do this, someone has trespassed into your house. I'm much more concerned with strangers stomping around my living room than I am about someone sniffing my WiFi traffic.
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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 u
Re: (Score:3)
OR more appropriately, wifi isn't 1st choice for security.
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:Has been for years. (Score:5, Insightful)
It is secure with regard to the design specification. The client does need to have the plain-text password or it cannot authenticate itself. If you do not want a plain-text password to be available to the entity storing it (and that is what password protection is all about), then you cannot use a mechanism where the plain-text password needs to be supplied. At best this is a Wi-Fi protocol vulnerability.
Re: (Score:3)
Re: (Score:2)
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).
Re: (Score:2)
Re: (Score:2)
A business network should be using per-user WiFi authentication (like WPA-Enterprise), already avoiding this problem.
Re: (Score:2)
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 p
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: (Score:2)
NetworkManager uses the keyring if you keep the passwords user-only. As soon as you enable the connection to start without any user being logged in, a wallet is useless.