Posts: 14,807
Threads: 342
Joined: Mar 2018
Reputation:
610
I see that foir WPA3-SAE the requirement is that a plaintext password must be used instead of a pre-shared key.
Code: [wifi-security]
key-mgmt=sae
sae_password=timtimtimtim
I've gone ahead and updated Network Config and related code but I have no way to test on my end because my WiFi network doesn't support WPA3.
When I've committed the changes I'll post a patch that can be tested.
Posts: 2,185
Threads: 47
Joined: Mar 2020
Reputation:
104
Am I understanding correctly that to use WPA3 we have to store the password in plain text? Seems like a regression is security rather than an upgrade in that case.
----------------
Robert
Posts: 15
Threads: 1
Joined: Nov 2024
Reputation:
0
I've re done the tests I did Friday and took another look at the documentation again. And yes it's plain text that is needed. When you connect on the command line it initially connects, on reboot it will failback to AP mode. When you create the connection manually it also writes a plaintext password in to the config.
It's not a security issue as the way WPA3 works is different. It uses the password as a authentication method to authenticate your allowed to connect, it doesn't even send the key it derives another token from it so it never goes across the airwaves. All cryptographic keys and data are no longer derived from the key. All that is handled internally in the WPA3 dragonfly protocol. Storing the plaintext is not really different than storing the hashed version at this point as both are purely to authenticate that your allowed to connect rather than encrypting traffic that could then be decrypted using a key. WPA3 was designed to get around offline attacks. Overall a bit step forward in security.
In the UI probably best to rename it from WPA3-SEC to just WPA3 as there is just two modes, sae (personal) and the enterprise mode. So nicer for users to just see WPA3, reduces confusion. If there is already key in there clear the text field and then write the clear text out to the config. WPA2 using the wpa_supplicant hashing is cool as is.
I didn't try it in mixed mode, i.e router in WPA2+WPA3 but should work just fine. I did get some odd results back from my router, It reported that the WPA3 was in WPA2 mode on a WPA3 only setup. All looks good and working correctly, that was probably down to a mode set on the Broadcom driver. That test will have to wait for another day but as that's a bit more in depth, but all working great.
I tested using a DrayTek, would be good to get some other test results, especially what the router shows after the connection. I'm outta time for the next few weeks. All working good here so will use it in WPA3 mode. When I get some more time I'll do some other test in to the strange result.
Posts: 6,526
Threads: 189
Joined: Apr 2018
Reputation:
268
Only root can read/write the NetworkManager connection profiles.
The insecurity issue here is that moOde’s default user is a “sudoer”. Keep your login credentials safe, just as you should for any computer connected to a network.
Regards,
Kent
Posts: 2,185
Threads: 47
Joined: Mar 2020
Reputation:
104
(03-16-2025, 12:40 PM)TheOldPresbyope Wrote: Only root can read/write the NetworkManager connection profiles.
The insecurity issue here is that moOde’s default user is a “sudoer”. Keep your login credentials safe, just as you should for any computer connected to a network.
Regards,
Kent
Yeah, that's the bit I find disturbing. Fair enough that just knowing the password won't let you decrypt in flight traffic but it does allow you to connect to the network as if you had every right to be there.
Well, I don't have WPA3 and won't be upgrading any time soon so it's academic really
----------------
Robert
Posts: 14,807
Threads: 342
Joined: Mar 2018
Reputation:
610
(03-17-2025, 07:25 AM)the_bertrum Wrote: (03-16-2025, 12:40 PM)TheOldPresbyope Wrote: Only root can read/write the NetworkManager connection profiles.
The insecurity issue here is that moOde’s default user is a “sudoer”. Keep your login credentials safe, just as you should for any computer connected to a network.
Regards,
Kent
Yeah, that's the bit I find disturbing. Fair enough that just knowing the password won't let you decrypt in flight traffic but it does allow you to connect to the network as if you had every right to be there.
Well, I don't have WPA3 and won't be upgrading any time soon so it's academic really 
Since WPA3-SAE requires a plaintext password instead of a one-way hash like WPA-PSK it makes it impossible to store it securely because to do so requires that the plaintext can't be recovered i.e., it has to be converted to a one-way hash.
One thing that could be done is to never display the password for WPA-SAE. It would always need to be entered when saving the Network Config form. This at least keeps it out of easy Browser console inspection. Someone would then need to know the logon password for the Pi in order to view it which like knowing the password for any OS gives you access to lots of things.
There may be other approaches.
Posts: 2,185
Threads: 47
Joined: Mar 2020
Reputation:
104
(03-17-2025, 12:21 PM)Tim Curtis Wrote: (03-17-2025, 07:25 AM)the_bertrum Wrote: (03-16-2025, 12:40 PM)TheOldPresbyope Wrote: Only root can read/write the NetworkManager connection profiles.
The insecurity issue here is that moOde’s default user is a “sudoer”. Keep your login credentials safe, just as you should for any computer connected to a network.
Regards,
Kent
Yeah, that's the bit I find disturbing. Fair enough that just knowing the password won't let you decrypt in flight traffic but it does allow you to connect to the network as if you had every right to be there.
Well, I don't have WPA3 and won't be upgrading any time soon so it's academic really 
Since WPA3-SAE requires a plaintext password instead of a one-way hash like WPA-PSK it makes it impossible to store it securely because to do so requires that the plaintext can't be recovered i.e., it has to be converted to a one-way hash.
One thing that could be done is to never display the password for WPA-SAE. It would always need to be entered when saving the Network Config form. This at least keeps it out of easy Browser console inspection. Someone would then need to know the logon password for the Pi in order to view it which like knowing the password for any OS gives you access to lots of things.
There may be other approaches.
The fine people who developed the WPA3 protocols will know a darn sight more about security than I do, so I'm sure they would not have done this if it introduced anything insecure. It just doesn't "feel" right to someone who's been repeatedly thumped for storing passwords in clear throughout his career
----------------
Robert
Posts: 14,807
Threads: 342
Joined: Mar 2018
Reputation:
610
(03-17-2025, 01:12 PM)the_bertrum Wrote: (03-17-2025, 12:21 PM)Tim Curtis Wrote: (03-17-2025, 07:25 AM)the_bertrum Wrote: (03-16-2025, 12:40 PM)TheOldPresbyope Wrote: Only root can read/write the NetworkManager connection profiles.
The insecurity issue here is that moOde’s default user is a “sudoer”. Keep your login credentials safe, just as you should for any computer connected to a network.
Regards,
Kent
Yeah, that's the bit I find disturbing. Fair enough that just knowing the password won't let you decrypt in flight traffic but it does allow you to connect to the network as if you had every right to be there.
Well, I don't have WPA3 and won't be upgrading any time soon so it's academic really 
Since WPA3-SAE requires a plaintext password instead of a one-way hash like WPA-PSK it makes it impossible to store it securely because to do so requires that the plaintext can't be recovered i.e., it has to be converted to a one-way hash.
One thing that could be done is to never display the password for WPA-SAE. It would always need to be entered when saving the Network Config form. This at least keeps it out of easy Browser console inspection. Someone would then need to know the logon password for the Pi in order to view it which like knowing the password for any OS gives you access to lots of things.
There may be other approaches.
The fine people who developed the WPA3 protocols will know a darn sight more about security than I do, so I'm sure they would not have done this if it introduced anything insecure. It just doesn't "feel" right to someone who's been repeatedly thumped for storing passwords in clear throughout his career 
There prolly isn't anything in the WPA3 spec about storing passwords. Thats typically left up to implementation in a given OS.
On MacOS for example, once logged in you can open the Keychain app using the login password and then can view other stored passwords including the plaintext for WiFi SSID's. My guess is that the stored passwords are encrypted/decrypted using the login credentials. It's prolly similar for Windows.
I'm thinking that as long as the plaintext password is never stored in a variable that can be inspected by the Browser the only way to view it would be to login via SSH to the Pi. Something like that.
Posts: 15
Threads: 1
Joined: Nov 2024
Reputation:
0
Yes it sounds insecure but isn’t. Even if someone took your sdcard out your pi so had physical access they could just take the hashed value (WPA2) and authenticate in the same way as taking a random plain text password unmasked (WPA3) Makes no different as both ends just need to authenticate regardless. You take your password and it gets hashed on the pi and stored. The access point does the same. It never goes across the wire so doesn’t really mater. In the past when your hashed key was used to derive the data protecting the key with a one way (hash) helped in offline decryption, but as that isn’t a factor it’s a non issue. And the same goes for permissions in general, if the intruder is that far in the system or on your network there are far easier targets to go for than you music files. Any also someone with physical access. More in flight protection is a winner. Hope this helps.
Posts: 14,807
Threads: 342
Joined: Mar 2018
Reputation:
610
(03-17-2025, 10:17 PM)ultramode Wrote: Yes it sounds insecure but isn’t. Even if someone took your sdcard out your pi so had physical access they could just take the hashed value (WPA2) and authenticate in the same way as taking a random plain text password unmasked (WPA3) Makes no different as both ends just need to authenticate regardless. You take your password and it gets hashed on the pi and stored. The access point does the same. It never goes across the wire so doesn’t really mater. In the past when your hashed key was used to derive the data protecting the key with a one way (hash) helped in offline decryption, but as that isn’t a factor it’s a non issue. And the same goes for permissions in general, if the intruder is that far in the system or on your network there are far easier targets to go for than you music files. Any also someone with physical access. More in flight protection is a winner. Hope this helps.
I think we are talking about the case where a plaintext password to a WiFi network is visible in a WebUI. We certainly don't want that.
If a pre-shared key is visible it can't be used directly to sign on to a WiFi network from a client for example an iPhone, Mac or PC because they only accept plaintext passwords. Someone would need the technical expertise to know how to use a pre-shared key to authenticate.
|