# Why does Windows store Wi-Fi passwords in a reversible format?

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?

• Note that Linux may do this too, depending on how it is configured. – forest Aug 25 at 8:17
• @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 at 8:22
• @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. – jww Aug 25 at 8:46
• 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 at 9:00
• (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 at 9:14

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:

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:

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

• @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 at 9:29
• @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 at 10:01
• @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. – grawity Aug 25 at 11:50
• 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 at 22:02
• @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 at 16:46

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

Unfortunately, the other answers which claim that the original password is necessary for authentication are incorrect. 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 encrypt a handshake, called the 4-Way Handshake, between the client and the router where a random, per-session data encryption key is exchanged. It is also used for authentication.

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

• 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 at 8:15
• "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 at 8:48
• @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 at 9:07
• @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 at 9:10
• 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 at 12:58

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.

• "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 at 20:58
• 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 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 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 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 at 9:38