Asus new firmware doesn't allow spaces in WPA2/WPA3 passwords

[John Fitzgerald]

Am I correct in assuming here that the part about "encrypting the WPA password in NVRAM" is just speculation even though it's not clearly indicated as such? Or perhaps you meant to say that this is the case for the newer "AX" router models, but not for the older "AC" models. Is this what you mean?

Currently, I don't have access to any "AX" models; but so far, with all the ASUS routers that I do have access to (RT-AC68U, RT-AC86U, RT-AC88U, RT-AC5300, GT-AC5300) I can see that all WPA PSK strings are *not* stored in NVRAM in an encrypted form at all. They're all found in human-readable, plain-text format.

You can check & verify this by typing the following command on your router via an SSH terminal window:

nvram show | grep "_wpa_psk"

A bit off topic question: Why are the passwords stored in a "Guest" network that has been deactivated?
My expectation is that once a field has been turned off, the settings are not stored, yet they are there.
As a follow-up, how can one reset the single "guest" network, without factory resetting?

 

[ColinTaylor]

A bit off topic question: Why are the passwords stored in a "Guest" network that has been deactivated?
My expectation is that once a field has been turned off, the settings are not stored, yet they are there.

So that you can disable and re-enable the guest network without having to enter the configuration details each time.

As a follow-up, how can one reset the single "guest" network, without factory resetting?

I guess you could delete all the relevant nvram variables, but that's a bit of a sledge hammer approach.

 

[John Fitzgerald]

So that you can disable and re-enable the guest network without having to enter the configuration details each time.


I guess you could delete all the relevant nvram variables, but that's a bit of a sledge hammer approach.

Thanks for the answer.
I wish there was a way to reset/blank each field/guest network individually.

 

[Yota]

Am I correct in assuming here that the part about "encrypting the WPA password in NVRAM" is just speculation even though it's not clearly indicated as such? Or perhaps you meant to say that this is the case for the newer "AX" router models, but not for the older "AC" models. Is this what you mean?

Currently, I don't have access to any "AX" models; but so far, with all the ASUS routers that I do have access to (RT-AC68U, RT-AC86U, RT-AC88U, RT-AC5300, GT-AC5300) I can see that all WPA PSK strings are *not* stored in NVRAM in an encrypted form at all. They're all found in human-readable, plain-text format.

You can check & verify this by typing the following command on your router via an SSH terminal window:

nvram show | grep "_wpa_psk"

@ColinTaylor is right, I misremembered, the WiFi password is currently not encrypted, only the admin password is encrypted.

A bit off topic question: Why are the passwords stored in a "Guest" network that has been deactivated?
My expectation is that once a field has been turned off, the settings are not stored, yet they are there.
As a follow-up, how can one reset the single "guest" network, without factory resetting?

I answered a similar question a few days ago, here are some ways to restore to default settings by modifying nvram.

 

[Yota]

My apologies to everyone, I was using random WiFi passwords, and when I checked my nvram, I mistakenly read the random wifi passwords generated by the script as Encrypted wifi passwords. That's why I speculate that their lack of support for spaces has something to do with encrypted wifi passwords, thanks to @Martinski and @ColinTaylor for pointing out my mistake.

Now that the wifi password is NOT encrypted, for anyone, you guys will be able to try using SSH to enter the password with spaces:

2.4 GHz

nvram set wl0_wpa_psk='your password'
# Use single quotes to avoid escaping

nvram commit
# Save Setting

service restart_wireless
# Restart wireless

2.4 GHz GuestWiFi 1

nvram set wl0.1_wpa_psk=''
nvram commit
service restart_wireless

2.4 GHz GuestWiFi 2

nvram set wl0.2_wpa_psk=''
nvram commit
service restart_wireless

5 GHz

nvram set wl1_wpa_psk=''
nvram commit
service restart_wireless

5 GHz GuestWiFi 1

nvram set wl1.1_wpa_psk=''
nvram commit
service restart_wireless

 

[Martinski]

The same is true on the AX models. The WiFi passwords are not encrypted. It is the main "admin" password that is encrypted as well as the Samba/FTP accounts.

And also the VPN account passwords are encrypted in NVRAM (well, at least the OpenVPN Server account passwords certainly are).

 

[Martinski]

My apologies to everyone, I was using random WiFi passwords, and when I checked my nvram, I mistakenly read the random wifi passwords generated by the script as Encrypted wifi passwords. That's why I speculate that their lack of support for spaces has something to do with encrypted wifi passwords, thanks to @Martinski and @ColinTaylor for pointing out my mistake.

Thank you for the clarification & explanation. Your candor is also appreciated.

Now that the wifi password is NOT encrypted, for anyone, you guys will be able to try using SSH to enter the password with spaces:

Yeah, that would probably work; however, if the user, later on, decides to change some parameter/option in the "Wireless --> General" web GUI page, they will likely encounter the problem described by @Kritiker in his post here where he found himself unable to make any changes because of the blank spaces present in his WPA PSK string. At the GUI level, there's usually some code that "sanitizes & validates" user entries to make sure they conform to whatever requirements & constraints that have been set in place; and this happens every time you go into the Web GUI page and click on the "Apply" button. In some cases, simply opening & closing a Web GUI page may trigger the code that sanitizes & validates user entries on that particular page.

This means that for those users who really want/need to have blank spaces in their WPA password(s), they will have to keep in mind the "side-effects" in the Web GUI after including any blanks spaces via CLI into the corresponding NVRAM key/value pairs.

 

[ColinTaylor]

And also the VPN account passwords are encrypted in NVRAM (well, at least the OpenVPN Server account passwords certainly are).

I did wonder about that. But I don't have any VPN servers with password access defined. The VPN client (e.g. NordVPN) passwords are not encrypted and are in plain text.

 

[Martinski]

The VPN client (e.g.NordVPN) passwords are not encrypted and are in plain text.

Well, that's curious and not really surprising. The DDNS account passwords (e.g. NO-IP) are not encrypted in NVRAM either.

All available info so far indicates that ASUS doesn't really have a consistent, uniform methodology to store all sensitive data (such as account passwords) in an encrypted format. It's only after some years that ASUS has been implementing encryption of passwords, and it's being done haphazardly since it's only for some account passwords but not others. Other router manufacturers have the same problem so this is not unique to ASUS at all.

My guess is that the issue is not writing the code to perform symmetric encryption on sensitive data before storing it into NVRAM. That part is fairly simple to write in C code using the existing OpenSSL libraries, and ASUS has obviously done it already.

The main barrier might be that there's not an overall layer of abstraction (which accounts for encrypted entries) between NVRAM and the various other modules that currently make calls to store/retrieve the desired key values directly into/from NVRAM. An intermediate abstraction layer could be written to inherently know which NVRAM entries must be encrypted and would automatically encrypt & decrypt during storage & retrieval without the caller needing to know in what format the NVRAM key values are actually stored. Implementing this new API and making modifications to all affected modules would probably require some architectural changes which, in turn, would require some serious regression testing. And all this takes more resources, time & money. And there's the rub, ultimately.