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.

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?

...so you're saying Linux needs something like the OS X Keychain [wikipedia.org]?

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

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.

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.

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.