66

Running

netsh wlan export profile key=clear

in PowerShell will dump your current stored Wi-Fi settings, including the password, into xml files inside of whatever directory you are currently in.

Why is it that Windows would store credentials in a reversible format? Why is it not just storing the hash of the password that it sends access points to complete the handshake and establish connection?

Loovjo
  • 107
  • 2
Wazanator
  • 741
  • 1
  • 6
  • 7
  • 11
    Note that Linux may do this too, depending on how it is configured. – forest Aug 25 '19 at 08:17
  • 1
    Probably worth mentioning... The RFCs *do not* use plaintext passwords in their protocols. See, for example, [RFC 4017, Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs](https://tools.ietf.org/html/rfc4017). –  Aug 25 '19 at 08:21
  • 4
    @jww Yeah but that's WPA2-EAP, not WPA2-PSK. You're still correct though. No password is sent in the clear (not even a hash is sent in the clear). It's used to derive an encryption key. – forest Aug 25 '19 at 08:22
  • What are you hoping to achieve by saving the password in a non-reversible format? – marcelm Aug 25 '19 at 08:39
  • 1
    @marcelm Usually the intention is to make password reuse a little less dangerous. – forest Aug 25 '19 at 08:43
  • 20
    @marcelm - The non-obvious threat is, those password lists are shipped to the cloud for companies like Apple, Google and Microsoft to fondle, and Law Enforcement and other miscreants to obtain. The password is blown after the first sync or backup. –  Aug 25 '19 at 08:46
  • 8
    Well, I was really asking the OP, but anyway... @forest, WiFi passwords are usually shared with multiple people, meaning reuse is already dangerous. @‍jww If Windows stored the PSK (essentially a hash of the password + SSID) instead, then those entities could fondle that instead. Note that aside from password reuse, the PSK is equally dangerous to your WiFi network as the password is. – marcelm Aug 25 '19 at 09:00
  • 16
    (What I'm really trying to determine is whether the OP understands how the authentication works and wants Windows to store the PSK instead, or if they think that the usual server-side password hashing could be used here) – marcelm Aug 25 '19 at 09:14
  • 2
    @forest It does. All operating systems do. – Boann Aug 25 '19 at 12:18
  • Thanks everyone I understand the protocol a lot better now. I was mostly surprised that it stores it like this I suppose because I was pretty certain that it sends it hashed as part of the handshake which to me meant you really don't need the plaintext version. This method makes a lot more sense when you remember that on most Wi-Fi networks everyone will be using the same passwords and if they have this level of access to your device then they would have access to the hash as well. – Wazanator Aug 25 '19 at 14:46
  • @marcelm Many ppl consider the pattern of their pw even more sensible then their exact value. – curiousguy Aug 25 '19 at 17:41
  • 2
    @Wazanator if a service accepts a precomputed hash of a secret, then that's no different than just having the hash be the secret. The security is no better, and will often be worse. – OrangeDog Aug 26 '19 at 13:38
  • Additionally windows provides the option to share the password btween your Phone, PC and even with friends who have a live account. Since this option was designed to be available on other platforms via e.g. an Android App, the plaintext password was the only way, since for example android doesn't provide a way for Apps to connect to a new Wifi with a password-hash. – Falco Aug 27 '19 at 07:58
  • As a user, I'm more mad that Windows is the only OS that does this. As a privacy conscious person, I agree with jww that it's probably feeding many databases. However, regardless of whether or not it's stored in plaintext, it's foolish to presume that these same companies, all of which have their own OS's, are not vacuuming them up pre-hashing anyways. – YetAnotherRandomUser Aug 27 '19 at 18:13
  • @jww Do you have any evidence to support that conjecture? I don't believe it to be true. Not that I'd be surprised either way. Sounds like a consumer class-action lawsuit waiting to happen though. – voices Aug 27 '19 at 21:02

3 Answers3

122

tl;dr- Windows is acting as a password manager, and like all password managers, it must remember the passwords it manages. You're probably thinking of the thing where servers are supposed to store hashes instead of passwords; that strategy doesn't apply here.

@forest's answer demonstrates a major caveat – that, if we assume a wireless network will always use a specific protocol that starts by hashing the password, e.g. WPA2, then Windows could forget the original password in favor of the protocol-specific hash.

Why is it that Windows would store credentials in a reversible format? Why is it not just storing the hash of the password that it sends access points to complete the handshake and establish connection?

Windows is serving two different roles here:

  1. Password manager:
    Windows can remember network passwords for you. When it does this, it's acting as a password manager. Like any other password manager, it must store the passwords it manages.

  2. Client:
    Windows must convince the WiFi network that it knows your password. To do this, it must know your password.

If you're concerned about Windows storing your password, it'd seem like you can just stop using its password management function. However, you'll still need to supply Windows with a network password in order to log into a network, much like you must supply an email portal with your email password to log in.

Note: The advice you're thinking of applies to servers, not clients.

You're probably thinking of the thing where a server shouldn't remember plaintext passwords, but rather a hash of them. That doesn't apply here since Windows isn't the server.

You can hash the WiFi password if you like, but then the hashed password would be the new password. This'd basically be the same thing as using a key-derivation function to generate your WiFi password.

Exception: Protocol-specific hashes can be retained.

The above answer is written for a general-case protocol.

However, specific protocols may call for having the password hashed, such as in the popular wireless protocol, WPA2. If we assume that the network will always use a specific protocol like WPA2 across all access points and time, then we can forget the original password if we just retain that hash.

The issue with retaining just the hash is that it's not the network password so much as the protocol-specific network password. This is, a client that retains just the hash under one protocol would break if the network updated to WPA3, or if they went in range of an older WPA access point, etc..

Community
  • 1
Nat
  • 1,443
  • 2
  • 11
  • 13
  • _To do this, it must know your password._ – No, it just needs to know a hash of the password (4096 iterations of PBKDF2-HMAC-SHA1 with a 256-bit output, using the ESSID as the salt). – forest Aug 25 '19 at 07:57
  • 5
    @forest I updated the above answer in an attempt to incorporate your point -- does it look about right to your eye? What I wanted to communicate was that clients, unlike servers, must retain their secret in full in the general case -- though if we assume a specific protocol will always be used, e.g. WPA2 (which wouldn't be a bad assumption for the past few years in many scenarios), then that protocol could specify a hashed reduction of the secret. – Nat Aug 25 '19 at 09:29
  • It's a lot better but the middle section still claims that Wi-Fi (or protocols in general) need to know the original password. E.g. _Windows must convince the WiFi network that it knows your password. To do this, it must know your password._ is still wrong for Wi-Fi and for most authentication protocols. – forest Aug 25 '19 at 09:32
  • 7
    @forest Huh, that could be tricky to word. I mean, the truth is that the client (Windows) must convince the authenticator (the network access point) that it had knowledge of the secret (the password), which proves its authenticity as a legitimate client that should be allowed to join. This is, I find the client's obligation to prove knowledge of the secret to be inescapable. I appreciate your excellent point that the client can lose full knowledge if it knows it won't be forced to prove it, e.g. it can reduce to a hash if a hash can be assumed sufficient, but that feels like a fold. – Nat Aug 25 '19 at 10:01
  • It doesn't need to _send_ the secret. What it does is encrypt a handshake which contains an authenticated checksum. I think it's called the MIC. It will fail to verify if the PSK is incorrect, but the PSK is never sent. https://en.wikipedia.org/wiki/IEEE_802.11i-2004#Four-way_handshake – forest Aug 25 '19 at 10:02
  • Also, https://security.stackexchange.com/q/66008/165253 explains how it's cracked, which may be helpful. – forest Aug 25 '19 at 10:07
  • 12
    @forest: Re "it just needs to know the hash": It's true for WPA2-PSK but not necessarily for WPA2-EAP, which might use PAP or EAP-GTC. And if I recall correctly, this will no longer be true for WPA3-PSK using SAE, and clients will need to know the original plaintext password again. – user1686 Aug 25 '19 at 11:50
  • But when I changed an AP from WPA to WPA2, Windows refused to connect to the network and asked the pw again. – curiousguy Aug 25 '19 at 17:44
  • @curiousguy That's weird; I wonder why it'd do that? That'd be neat to try to experiment with later -- what version of Windows? And guessing you kept the said SSID and password, just changing from WPA2 to WPA? – Nat Aug 25 '19 at 17:50
  • @Nat Windows 6.3; WPA -> WPA2 not the other way around; `netsh wlan export profile key=clear` works and show all pw. Can't retry now because Wifi has issues and shutdowns all the time. – curiousguy Aug 25 '19 at 17:55
  • 40
    The "password" is whatever you need to know to access the resource. If all you need to know is the hash, then the hash *is* the password. and storing the hash in the clear would be storing the password in the clear. Servers store hashes of the thing that clients need to send to them. If clients only had to send them the hash, the server storing the hash would not provide any security. – David Schwartz Aug 25 '19 at 22:02
  • 1
    @DavidSchwartz That's not the correct definition, even if the point you are making is correct. – forest Aug 26 '19 at 06:04
  • 1
    This might be a naive question, but even if Windows has to store the password, why does it make it accessible to (any) user? Wouldn't be possible to store it in a way that only makes it accessible if the user pretends to be a wifi connection. – sgf Aug 26 '19 at 09:38
  • 1
    @sgf Sure, they could design it to be largely inaccessible to the average user, e.g. by simply omitting a GUI to view it. I suspect that there's some lack of motivation, though; I mean, I haven't heard of people having their WiFi passwords lifted from their saved-networks list being a problem before, especially since such passwords are usually shared in residential or coffee-house-like environments. – Nat Aug 26 '19 at 09:48
  • In the last paragraph you might want to mention that if the protocol just needs the hash, then the hash *is* the password and there is no security gained by storing the hash instead of the original password. – AndreKR Aug 26 '19 at 11:59
  • 6
    @forest You're _technically_ correct that the hash isn't the password, but the problem with saving the password in the clear is not "saving the password in the clear" per se; it's "saving [the thing that can be used to access the resource] in the clear", which is why David is _functionally_ correct. This is a fundamental problem with any password manager: It must somehow be able to provide [thing] to access the resource. The only wayt to deal with this is to encrypt the entire [thing] store with a key derived from a password the user can remember. – Monty Harder Aug 26 '19 at 16:46
  • 2
    @sgf They used to do that, actually, and it was a royal pain in the a$$ for anyone who forgot their wi-fi password. – user253751 Aug 27 '19 at 00:04
  • So then they changed it, so that people who forgot their wi-fi password can find out what it is. – user253751 Aug 27 '19 at 00:23
35

The password is never sent. It is hashed, and that hash is used (indirectly) for encryption.

The password can be passed through an algorithm called PBKDF2-HMAC-SHA1 with 256-bit output and a salt derived from the ESSID (network name) to generate the PSK, a raw 256-bit key. This PSK is used to authenticate a handshake, called the 4-Way Handshake, between the client and the router where a random, per-session data encryption key is derived.

The reason Windows does not store the raw PSK rather than the password is for better user experience. If someone doesn't know their password when adding a new device to the network, they can view it on Windows without needing to connect to the router's administrative panel. Storing passwords in an irreversible format is useful for servers where there exists a risk that a database of passwords will be stolen en masse. For a mere personal Wi-Fi password, this risk is far less pronounced.

Please note that this only applies to WPA2-PSK. There are other Wi-Fi encryption standards, even under the WPA2 label, which do not use any kind of pre-shared password, such as WPA2-EAP, which can negotiate a key on the fly.

To demonstrate that this is possible, this can be done on Linux with wpa_passphrase. We will use the sed command to remove commented lines, which contain a plaintext copy of the original password:

$ wpa_passphrase MyNetworkName MySecretPassword | sed '/^\s*#/d'
network={
    ssid="MyNetworkName"
    psk=652f56f4a475711020fe175020912964f30bede1de36e7c08ed9da7eaf6d68c2
}

The line which was commented out containing the original passphrase has been removed. It's important to be aware that this PSK, if stolen, will give the attacker the same capabilities as if they stole the original password. They will be able to decrypt stored sessions and authenticate to your access point. However, they will not know the original password itself, which may be useful if it is used elsewhere (a bad idea).

Glorfindel
  • 2,263
  • 6
  • 19
  • 30
forest
  • 65,613
  • 20
  • 208
  • 262
  • 2
    Thanks for the correction! I was actually going to add in a section about how the connection protocol could be altered by both the client and server agreeing to use a hash of the password as the new password, such that the original may be forgotten if either side wishes, but I guess that's already how it works! – Nat Aug 25 '19 at 08:15
  • Is this alteration called anything? For example, we could alter email logins the same way, where we salt an email password with the email address to generate the effective password, such that a user no longer needs to store their email password in reversible format. Then, I guess, email portals could have a side-page for users who want to log-in with their hash, and email clients like Microsoft's Outlook could forget the original password. Not that this would seem particularly beneficial, especially given the increase in complexity liable to confuse users, but does it have a name? – Nat Aug 25 '19 at 08:29
  • @Nat I don't think there's a specific term. It's just using precomputation rather than computing the hash on-the-fly. While not totally unique, it's not a common thing. WPA2 just happens to do it that way. – forest Aug 25 '19 at 08:30
  • 1
    Does this only apply in the case of WPA2 then? For example, would a client break if it stored just the PSK and the network switched to WPA or WPA3? – Nat Aug 25 '19 at 08:46
  • @Nat I'm not sure about WPA (I think it uses the same PSK generation method), but WPA3 is a completely different protocol, so the network would ask for a new password, and the client would need to supply it separately. – forest Aug 25 '19 at 08:47
  • 10
    _"Storing passwords in an irreversible format is useful for servers where there exists a risk that a database of passwords will be stolen en masse. For a mere personal Wi-Fi password, this risk is far less pronounced."_ - That is not the reason for the difference; a server where a user presents his credentials can use a hash to _verify_ those credentials. A client that has to authenticate itself _needs_ the original credentials (in the case of WiFi, either the password or the derived PSK) to prove its authenticity to the server, it cannot use a mere hash like say, a website can. – marcelm Aug 25 '19 at 08:48
  • @marcelm The PSK itself is a hash (well, through a KDF) of the password. – forest Aug 25 '19 at 08:48
  • 10
    @forest I'm fully aware of that, but that's irrelevant to the point I was making. Windows _could_ just store the PSK, but that's still storing original credentials that anyone could use to connect to the WiFi network. It simply doesn't have the luxury of only having to _verify_ password that are offered in plain-text. – marcelm Aug 25 '19 at 09:07
  • 3
    @marcelm That's true. My point is only that the raw ASCII password is not necessarily required, so if you (foolishly) re-used it for your bank, someone who steals your router or computer isn't going to log into your bank with said password. Windows doesn't hash it simply because that benefit isn't worth the UX penalty. – forest Aug 25 '19 at 09:10
  • @forest Agreed. Because WiFi passwords are usually shared amongst a group, I more or less assumed people wouldn't reuse them for anything important anyway. This would make the importance of secrecy of the password and the PSK basically equivalent. But perhaps I have too much faith in users' password hygiene. – marcelm Aug 25 '19 at 09:23
  • 6
    The Windows WiFi layer doesn't know the authentication method that will be used by the Access Point's authenticator. That will only be known at connection time during the authentication protocol negotiation. Authentication protocols (EAP methods) are layered into Windows and each can be different. So the best it can do is retain exactly what the user supplied. Unfortunately there are methods like EAP-GTC which do simply pass plain text. – DaveM Aug 26 '19 at 12:58
  • While I agree that password reuse can be an issue, I think it might be worth clarifying that storing the PSK as opposed to the plaintext password *does not* make your wifi any more secure. If an attacker gets ahold of either, your network is equally compromised. Or perhaps I'm wrong? Either way, I think the answer would be improved by spelling it out a bit more. – Blackhawk Aug 26 '19 at 22:11
  • Also, the comparison with server-based hashes is not exactly fair. As an attacker, if I get ahold of your hashed facebook password (and salt), I have to crack it and get your password before I can log in. However, if I got ahold of the PSK, it's just as good as your password for compromising your wifi network (as you describe). – Blackhawk Aug 26 '19 at 22:19
  • On second read through, most of what I'm asking for is there - it's just that the way it is structured/worded now, it really reads like you're saying "Everyone else is wrong - storing just the hash would make your network more secure". Maybe you could revise slightly? – Blackhawk Aug 26 '19 at 22:23
  • [**_Ratcheting_**](https://crypto.stackexchange.com/questions/39762/what-is-a-ratchet)! The alteration where both sides agree to hash their shared secret such that they can forget the original -- it's called "_ratcheting_". Weird that there's not a Wikipedia page for it. – Nat Aug 27 '19 at 00:20
  • @Nat - You are re-characterizing Ratcheting incorrectly. While your reference shows an example in What's App where the key is changed every message, most WiFi methods don't work like that. The key handshake determines a "fixed" value key until a key renewal period expires, and a new handshake creates a new session key. – DaveM Aug 27 '19 at 01:11
  • @DaveM I was referring to how we reduce a user-specified password to, e.g., WPA2's PSK. It's a single-step ratchet in that we start with a shared secret that both sides irreversibly mutate such that they may forget the original. – Nat Aug 27 '19 at 01:15
  • 2
    Since the question nowhere mentiones WPA2, could you specify in your answer that this is only true for WPA2-PSK Networks and not for other forms of Wifi with password ? As it stands, the answer seems to suggest that all Wifi-Networks use this exact protocol. – Falco Aug 27 '19 at 07:55
  • 1
    @Falco Good catch. Yes I'll edit it now. – forest Aug 27 '19 at 08:20
0

I would guess that the reason windows stores this information in reversible format is so that it can be read by the OS later.

You can read the WiFi key from settings anyway, which some people find useful to tell their friends what the wireless key is so they can join the network. (windows 10 used to have a feature called "wifi sense" that shared your key in plaintext to your contacts. info here)

I don't see how this is a security issue, as someone with access to a machine with the key is already on the network anyway, and even if they only had access to a hashed key, they could use that to auth to the network.

Personally, the only reason I have a wifi key in the first place is to enable WPA2. Apparently, it'll no longer be required for WPA3 as encryption and authentication are separate processes.

bobsburner
  • 101
  • 1
  • "I don't see how this is a security issue" because people re-use passwords. So the password potentially unlocks access to things other than the wifi network. – Peter Green Aug 26 '19 at 20:58
  • 1
    My concern was from a red team perspective of someone walking into an office and grabbing credentials for the internal Wi-Fi. Hopefully IT is whitelisting devices but I've definitely heard of places that don't. – Wazanator Aug 26 '19 at 22:56
  • If someone has access to the machine, wouldn't they be able to access the wifi anyway? (even if they only get a hashed version of the key like is suggested by OP. Unless the user can't become admin, or something) – bobsburner Aug 27 '19 at 13:42
  • @bobsburner yes I was thinking the same thing, admin can access but if you are a normal user you can't. Not sure why that isn't the case but that's probably best for another question :) – Wazanator Aug 27 '19 at 18:23
  • Do you mean just through the control panel, or are you suggesting without an admin login it's impossible to get the wifi credentials? Also, more to your earlier question, if the network is WPA(2) PSK (with a single key that's the same for everyone) how could IT maintain a whitelist? – bobsburner Aug 28 '19 at 09:38