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?"
I know it's FUD! It's anti-Linux, which by nature is perfect!!! -Stallman fan
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.
I have Verizon FIOS, and the password is printed on the side of the router.
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.
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.
I know it doesn't really change the fact that it's non-secure, but this isn't really news.
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.
Report it as a bug. Ask for improved security.
If the maintainer ignores the bug report and fails to act, uninstall the app and find one that works as you wish. Publicize the lackof response of the maintainer withinh the community.
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
Only root has access to the file. If someone has root access on your computer, the damage could be far worse.
Making security more cumbersome does not necessarily make it more secure. As it is, the failure modes are fairly obvious, and so would be the on-site policies and precautions. In a system that stored encrypted passwords, they might not be.
This is like saying that because a bank manager can get into a vault and see the money, it's insecure. If someone breaks into the bank it doesn't really matter that the manager can get into the vault. Should it at least be hashed? Sure, but to say that something stored under root is a problem is kind of odd. Then again I encrypt my drive by default, so the live cd vector isn't a problem for me.
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
# cat /etc/hostname.iwn0
nwid attwifi
wpakey P@ssW0Rd
dhcp
The solution is to encrypt your hard drive.
Anyone who connects a GNU/Linux box via wireless network has no concern for security.
You see, when the hackers/crackers (not the southern white people) get the password, they'll think it's some really really really really obfuscated-genius-sick-crypto and spend years and much computer time trying to crack it.
See?
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.'"
It uses gnome-keyring. All passwords are saved in the keyring. And if its not open a dialog popups to open it.
(For those who don't know, gnome-keyring encrypts everything).
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.
sounds gross but it's really nonsense i just wanted to see how i 'look' from out in the kingdumb. reminding myself how unexcitingl my dealings are helps me feel more secure? free the innocent stem cells.
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?
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.
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!
I'm running Ubuntu and using Network Manager. I checked the directory where the passwords are reported kept and found two things:
1. All the files in that directory are readable only by root. This means someone needs to have root access to your system (or phsycialy access to an unencrypted drive) to read the network profiles.
2. None of the files contained passwords for my wireless networks.
My conclusion is the article is A) wrong on multiple points and B) ignores that fact that if your box is already rooted than wireless passwords are the least of your worries.
And if you think it is, maybe you should read what Pidgin developers have to say about this..
These yearly "$PROGRAM is storing my passwords in plain text! Won't somebody think of the children!" stories are very tiresome...
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
One does not require passwords, encrypted disks, or other pseudo-unbreakable crypto keys.
As long as one has enough adequate monitoring in place!!!
[wdw]
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.
> Simple. Stop using Gnome shit.
Does that include SystemD?
(* hides behind a rock before the systemd thugs come to beat him up *)
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 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.
Sorry bonehead - if you don't expect admins to be able to access your data, your approach is fundamentally flawed.
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!
Has anyone noted that MS has done anything more meaningful than obfuscation in this regard? MS does offer a nice 'securestring' feature, but if they want to have automatic joining to a wireless network possible on startup without login, it's highly likely that they do something equivalent to this (plaintext or just pretending it's protected).
MS has their share of sins (NTLM hashes are pathetic in the SAM db, unattend files can be found all over the interent with posters thinking 'hidden' provides some meaningful protection when it's really just base64 encoded, etc.) In this case, I'd be hard pressed to identify a *meaningfully* more secure scheme unless requiring local console login to get net access.
Except with it stored unecrypted they don't NEED physical access, they merely need you to follow a few simple instructions and download their "free codec" or similar trick.
Linux fanboys can scream bloody murder and waste modpoints but that won't change reality and reality is its almost never the OS that is the weakest link, its PEBKAC. Hell look at Windows from Vista on up, you have the user running as a user and requiring elevation for anything more than trivial changes (sound familiar?) and it goes even one better than Linux by having the browser by default run with the lowest possible privileges, yet systems STILL get pwned, why? PEBKAC.
Linux users, like the Mac users before them got away with not having to worry about such things thanks to security by obscurity, but just as MacDefender signaled the end of that perk in OSX so too has the million Android infections signaled the end of SBO for Linux. I've seen Linux machines pwned in a week (look up the "KDE Look" bug for just one example) and I've seen Win2K boxes go from RTM to EOL without a single bug because at the end of the day its not the OS, although storing passwords in plain text is just stupid, but ultimately whether a system is secure or not comes down to whether the user has common sense and follows best practices.
Remember folks no matter how hard you work to foolproof a system the world will always come up with a bigger fool.
ACs don't waste your time replying, your posts are never seen by me.
one http://i.imgur.com/fZRHal3.png
two http://i.imgur.com/riiIbvX.png
Politics is Treachery, Religion is Brainwashing
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?
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.
Besides default password, is unique, and a bit more complicated than the default, non-unique password found on stand-alone routers.
If you reset the Verizon router It defaults back to the printed password .
I'm guessing you think you are too smart to read the instructions.
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.
> what happens when the user changes their password.
In systems like that it goes like this: user password is passed through key derivation function to get a key that is used to decrypt the actual, more secure key which is used for actual encryption. To change the password, you first decrypt the actual key with old pass and then reencrypt with new pass. There might also be separate procedure to replace the secure key.
> 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?
Yes, with this setup, you forget your password - you're SoL. Only way around is a backup of the decryption key in a separate place, protected with different pass you might remember, but it's more of a plan in case of key getting corrupted, not in case of user failure.
That's more or less the protocol used by, say, Windows EFS and TrueCrypt. iCloud secure backups seem to use something like that too, but I've no firsthand experience of that.
Since when did any hacker worth his salt need to know your WiFi password in advance of hacking your WiFi ?
Once you do a drive by demo using an Android smartphone in Access Point mode hooked up to a laptop running WireShark nobody puts a WiFi access point on their LAN anymore anyway...
Besides that if I have physical access to your machine and you haven't encrypted your private data it's game over....
Had a client once proclaim their servers were locked down tighter than a duck's arse and were unhackable, then I did my five minute reboot and boot into Knoppix routine to show them just how useless all that two factor auth was when I had physical access to their servers and they hadn't bothered to encrypt their data.
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 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.
So this "RJ-45 wire".... is it better than connecting the access point to the antenna using a wire completely made out of tinfoil?
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.
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.
hope u macfags have fun with ur overpriced shiny encrypted passwords!!!1
you still need it decrypted in order to use it, which requires that any secret information required to decrypt it is then at risk. This is turtles all the way down.
I'm pretty sure you mean 8P8C.
True, but as you say: the "password" is a generator seed, and the real access key is what's stored in plaintext. Also: this intermediate hash needs to be repeatable, so it can't really be salted (I can come up with a few over-engineered ways, like the AP sending back the salt in the handshake and you store the salt), so rainbow tables.... In any case, the actual authentication token is plaintext.
Support my political activism on Patreon.
> wpa_supplicant and most tools that use it store an intermediate hash of the password /etc/wpa_supplicant/wpa_supplicant.conf as some hash instead of plaintext?
> See also http://unix.stackexchange.com/questions/74500/wpa-supplicant-store-password-as-hash-wpa-eap-with-phase2-auth-pap [stackexchange.com]
>> Is there a way to store my password in
>> 1 Answer: Unfortunately I have to answer the question myself now. "Unfortunately" because the answer is "No, it is not possible".
Wat.
The system level service can store multiple copies of the wifi password, separately encrypted with the wallet key/login password/whatever of each user authorized to use the password.
If you can read the contents of files in my /etc, then I think you're already on my network. This is like worrying about a jigaw puzzle, where, one you solve it, it reveals the secret solution: "put the pieces where they fit."
I wanted to point out that here is a legitimate use case for TPM/HSM. Everyone was so frightened of the threat of DRM abuse that was driving TPM, that we all forgot that we do actually want some of those features.
# 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.
Now, can somebody tell me why this person used sudo?
Because the security hole exists between the chair and the keyboard, not in the operating system.
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.
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)
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?
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).
they can see what letter you typed in, so it's still insecure.
PS the overhead comes when it needs debugging. If finding that you've been attacked is obscured, then you're less secure.
It's "encrypted" in a method that is trivial to decrypt. Decrypting it by brute force would take several minutes.
Seriously, how the hell do you think it would work?
If your wireless connection connects only with the user's password as they log in, then you need to have every account set up the wireless connection.
If the OS uses a password to "encrypt" and when booting uses the password to decrypt WiFi access on boot, then boot has available IN PLAIN TEXT the password required.
If the OS uses a key to encrypt it, then it cannot be a passworded key and therefore access to the system to read the wifi password includes access to the passwordless key to decrypt it, and you have still got plaintext access to the wifi password.
Unless your boot up is to the GRUB system and no further, then your /boot partition needs to have in plaintext the decrypt key for /usr, /etc, /var and so on to boot the OS on /usr.
Unless your boot is "Please enter password to boot up computer" before it can boot the OS.
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.
Gnome stores passphrases to encrypted partitions _IN_PLAIN_TEXT in the gnome keyrings directory in the user's home, if you let it. Tails even does this. That's fucked. Gnome once again proves it has absolutely no idea about security. NEVER check that remember password box! NEVER store passphrases in plain text, anywhere or anyhow.
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...
Good example, wrong conclusions, using weak encryption like WEP is like using a bent nail in place of a lock for your basement - sure, someone has to intentionally pull it away to open the door but as police will explain unless the door was properly locked, it's treated as unlocked door i.e. owner neglect which at least here is enough for police to send you away instead of filing a case.
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
I don't care because most remote attacks have a problem with accessing /etc
I mean a person would have to steal my computer to get my wifi key. Does it really matter? I am writing a private book and should I encrypt that too? You see personally I don't care.
Yikes! Pidgin does store my passwords in plain text! But... but... but... Joomla too, in its configuration file! And... and almost every CMS by the way! Wait a minute... My Webmail system also stores the... waaaaaaaaaaah! database administrator password in plain text!
This is a conspiracy! We're all doomed! Shut them all down!