Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Security Encryption Linux

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?"
This discussion has been archived. No new comments can be posted.

Linux Distributions Storing Wi-Fi Passwords In Plain Text

Comments Filter:
  • NSA DID IT! (Score:5, Funny)

    by CajunArson ( 465943 ) on Tuesday December 31, 2013 @11:23AM (#45828927) Journal

    Must have been the NSA! I should have known that commit from was suspicious.

  • KNetworkManager (Score:5, Informative)

    by chill ( 34294 ) on Tuesday December 31, 2013 @11:23AM (#45828933) Journal

    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. []

    • Re: (Score:3, Funny)

      by MacDork ( 560499 )
      It won't matter what you use if you let anyone on your network with an android [] phone. Oh hai, let's back up everything to teh googles.
    • Re:KNetworkManager (Score:5, Informative)

      by Anonymous Coward on Tuesday December 31, 2013 @12:04PM (#45829383)

      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)

        by mveloso ( 325617 ) on Tuesday December 31, 2013 @01:32PM (#45830491)

        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)

          by Anonymous Coward

          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:5, Interesting)

        by TheCarp ( 96830 ) <> on Tuesday December 31, 2013 @01:33PM (#45830501) Homepage

        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.

  • by Anonymous Coward on Tuesday December 31, 2013 @11:24AM (#45828945)

    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.

    • by MacDork ( 560499 ) on Tuesday December 31, 2013 @11:32AM (#45829013) Journal
      If someone has physical access to your hardware, they're already in a position to do much worse. Encrypted drive? Let me just load this keylogger into BIOS [] mmm kay?
    • by gweihir ( 88907 ) on Tuesday December 31, 2013 @11:53AM (#45829257)

      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...

    • by bonehead ( 6382 )

      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.

      • by amorsen ( 7485 ) <> on Tuesday December 31, 2013 @12:15PM (#45829501)

        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.

        • by blueg3 ( 192743 ) on Tuesday December 31, 2013 @02:23PM (#45830999)


          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.

  • by Anonymous Coward

    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)

      by jones_supa ( 887896 )

      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)

        by Anonymous Coward

        They are not encrypted. For that it would be necessary to use a user private key. Instead, they are obfuscated with a system key: []

        They are trivial to recover.

        • 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?

      • by amorsen ( 7485 )

        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.

  • by allo ( 1728082 )

    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.

  • 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.
    • by chill ( 34294 )

      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.

  • And the problem is? (Score:2, Informative)

    by Anonymous Coward

    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.


    • by sqlrob ( 173498 )

      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)

        If the system stores an encryption key and a password, it's storing plaintext in an exotic format. If the system is capable of extracting the plaintext without user intervention, then it's storing plaintext in an exotic format. If it's OpenSSL encrypted, and the OpenSSL key is RIGHT THERE NEXT TO IT, it's in plaintext.
  • 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'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 :)

    • 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)

    by gweihir ( 88907 ) on Tuesday December 31, 2013 @11:41AM (#45829103)

    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.

    • 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)

        Your argument is that the password should be rot13 or base64 encoded.
      • by gweihir ( 88907 )

        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

    • by chill ( 34294 )

      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

  • 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 secu
  • by Bob9113 ( 14996 ) on Tuesday December 31, 2013 @11:41AM (#45829113) Homepage

    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.

  • 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 so
  • 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.

  • by Rob the Bold ( 788862 ) on Tuesday December 31, 2013 @11:47AM (#45829185)

    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.

  • They're (weak) access control features. Secure at the transport level.
    • by KDN ( 3283 )
      WPA2 with enterprise mode and AES transport is pretty secure, assuming the NSA hasn't FUBAR'ed AES. WEP and TKIP I would definitely put out to pasture.
  • by PvtVoid ( 1252388 ) on Tuesday December 31, 2013 @11:56AM (#45829293)
    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!
  • If you are using the WPA with PSK (Pre Shared Key), you need the plain text pre shared key to generate the PMK (Pairwise Master Key). Once you have the PMK, you really don't need the pre shared key. But if you change the access point or change the NIC on your machine you will need it to generate the PMK over again. If you are concerned, go to WPA enterprise mode with the Radius challenge response.

    Speaking of PSK security, you are using the mimimal PSK length of 20 (or was it 22?) characters to ensure

  • 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

  • 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,

  • 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.


  • by mrflash818 ( 226638 ) on Tuesday December 31, 2013 @12:09PM (#45829423) Homepage Journal

    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
    -rw------- 1 root root 399 Jul 4 13:22 Auto
    drwxr-xr-x 2 root root 4096 Jul 4 13:22 .
    robert@debian:/etc/NetworkManager/system-connections$ cat
    cat: Permission denied

  • by SteveAyre ( 209812 ) on Tuesday December 31, 2013 @12:14PM (#45829491)

    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.

  • by PPH ( 736903 ) on Tuesday December 31, 2013 @12:15PM (#45829509)

    No passwords stored as plaintext on my system's disk. Only on the yellow post-it stuck to the display.

  • by Sits ( 117492 ) on Tuesday December 31, 2013 @12:32PM (#45829749) Homepage Journal

    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?

  • by Todd Knarr ( 15451 ) on Tuesday December 31, 2013 @12:42PM (#45829899) Homepage

    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.

If all else fails, immortality can always be assured by spectacular error. -- John Kenneth Galbraith