Why does Windows store Wi-Fi passwords in a reversible format?How to securely hash passwords?How exactly does...
When calculating a force, why do I get different result when I try to calculate via torque vs via sum of forces at an axis?
European language movie, people enter a church but find they can't leave
Evaluated vs. unevaluated Association
Duplicate instruments in unison in an orchestra
When one problem is added to the previous one
How to check whether a sublist exist in a huge database lists in a fast way?
Does Yeshayahu 43:10b / 43:13a imply HaShem was created?
Where does learning new skills fit into Agile?
If the Shillelagh cantrip is applied to a club with non-standard damage dice, what is the resulting damage dice?
Command "root" and "subcommands"
"There were either twelve sexes or none."
How do proponents of Sola Scriptura address the ministry of those Apostles who authored no parts of Scripture?
Higman's lemma and a manuscript of Erdős and Rado
Photoshop: How can I change the layer type?
How to find out the average duration of the peer-review process for a given journal?
Filling a listlineplot with a texture
How long do you think advanced cybernetic implants would plausibly last?
Immediate Smaller Element Time Limit Exceeded
What does "rel" in `mathrel` and `stackrel` stands for?
Changing JPEG to RAW to use on Lightroom?
Papers on arXiv solving the same problem at the same time
Tex Quotes(UVa 272)
Handling Disruptive Student on the Autism Spectrum
Why did Khan ask Admiral James T. Kirk about Project Genesis?
Why does Windows store Wi-Fi passwords in a reversible format?
How to securely hash passwords?How exactly does 4-way handshake cracking work?Is it possible to securely store passwords using reversible encryption?Does Facebook store plain-text passwords?Is using MD5 in NTLMv2 protocol to store Windows passwords is secure?Windows Scheduled Task passwordsDoes Windows have a built-in password store?Does Outlook store plain-text passwords?How does Windows Server 2008 store local users' passwords?Why is the Store Passwords with reversible encryption option even there?An authentication protocol to prevent phishing & solve the problem of password reuse?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
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?
passwords windows wifi
New contributor
Wazanator is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
|
show 6 more comments
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?
passwords windows wifi
New contributor
Wazanator is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
3
Note that Linux may do this too, depending on how it is configured.
– forest
16 hours ago
2
@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
16 hours ago
6
@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
16 hours ago
4
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
16 hours ago
8
(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
15 hours ago
|
show 6 more comments
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?
passwords windows wifi
New contributor
Wazanator is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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?
passwords windows wifi
passwords windows wifi
New contributor
Wazanator is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Wazanator is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 8 hours ago
Loovjo
1052 bronze badges
1052 bronze badges
New contributor
Wazanator is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked yesterday
WazanatorWazanator
1166 bronze badges
1166 bronze badges
New contributor
Wazanator is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Wazanator is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
3
Note that Linux may do this too, depending on how it is configured.
– forest
16 hours ago
2
@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
16 hours ago
6
@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
16 hours ago
4
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
16 hours ago
8
(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
15 hours ago
|
show 6 more comments
3
Note that Linux may do this too, depending on how it is configured.
– forest
16 hours ago
2
@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
16 hours ago
6
@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
16 hours ago
4
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
16 hours ago
8
(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
15 hours ago
3
3
Note that Linux may do this too, depending on how it is configured.
– forest
16 hours ago
Note that Linux may do this too, depending on how it is configured.
– forest
16 hours ago
2
2
@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
16 hours ago
@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
16 hours ago
6
6
@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
16 hours ago
@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
16 hours ago
4
4
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
16 hours ago
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
16 hours ago
8
8
(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
15 hours ago
(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
15 hours ago
|
show 6 more comments
2 Answers
2
active
oldest
votes
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:
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.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..
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
17 hours ago
3
@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
15 hours ago
3
@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
15 hours ago
5
@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
13 hours ago
2
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
3 hours ago
|
show 6 more comments
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.
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).
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
16 hours ago
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
16 hours ago
1
"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
16 hours ago
3
@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
15 hours ago
2
@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
15 hours ago
|
show 5 more comments
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "162"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Wazanator is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f215864%2fwhy-does-windows-store-wi-fi-passwords-in-a-reversible-format%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
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:
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.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..
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
17 hours ago
3
@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
15 hours ago
3
@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
15 hours ago
5
@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
13 hours ago
2
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
3 hours ago
|
show 6 more comments
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:
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.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..
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
17 hours ago
3
@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
15 hours ago
3
@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
15 hours ago
5
@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
13 hours ago
2
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
3 hours ago
|
show 6 more comments
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:
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.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..
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:
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.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..
edited 15 hours ago
answered 19 hours ago
NatNat
8031 gold badge6 silver badges13 bronze badges
8031 gold badge6 silver badges13 bronze badges
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
17 hours ago
3
@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
15 hours ago
3
@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
15 hours ago
5
@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
13 hours ago
2
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
3 hours ago
|
show 6 more comments
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
17 hours ago
3
@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
15 hours ago
3
@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
15 hours ago
5
@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
13 hours ago
2
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
3 hours ago
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
17 hours ago
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
17 hours ago
3
3
@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
15 hours ago
@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
15 hours ago
3
3
@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
15 hours ago
@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
15 hours ago
5
5
@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
13 hours ago
@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
13 hours ago
2
2
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
3 hours ago
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
3 hours ago
|
show 6 more comments
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.
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).
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
16 hours ago
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
16 hours ago
1
"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
16 hours ago
3
@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
15 hours ago
2
@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
15 hours ago
|
show 5 more comments
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.
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).
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
16 hours ago
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
16 hours ago
1
"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
16 hours ago
3
@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
15 hours ago
2
@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
15 hours ago
|
show 5 more comments
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.
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).
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.
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).
edited 14 hours ago
answered 17 hours ago
forestforest
46.1k19 gold badges148 silver badges167 bronze badges
46.1k19 gold badges148 silver badges167 bronze badges
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
16 hours ago
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
16 hours ago
1
"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
16 hours ago
3
@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
15 hours ago
2
@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
15 hours ago
|
show 5 more comments
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
16 hours ago
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
16 hours ago
1
"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
16 hours ago
3
@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
15 hours ago
2
@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
15 hours ago
2
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
16 hours ago
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
16 hours ago
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
16 hours ago
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
16 hours ago
1
1
"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
16 hours ago
"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
16 hours ago
3
3
@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
15 hours ago
@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
15 hours ago
2
2
@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
15 hours ago
@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
15 hours ago
|
show 5 more comments
Wazanator is a new contributor. Be nice, and check out our Code of Conduct.
Wazanator is a new contributor. Be nice, and check out our Code of Conduct.
Wazanator is a new contributor. Be nice, and check out our Code of Conduct.
Wazanator is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Information Security Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f215864%2fwhy-does-windows-store-wi-fi-passwords-in-a-reversible-format%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
3
Note that Linux may do this too, depending on how it is configured.
– forest
16 hours ago
2
@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
16 hours ago
6
@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
16 hours ago
4
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
16 hours ago
8
(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
15 hours ago