Exported config file – SSID security keys re visible, not hashed!

Ikarus

Hello,
I’m doing some experiments with my new AP and this is what I found (very confusing):

1.)   If you save the config the SSID keys are NOT hashed. You can see them with all their beauty. This is very, very irritating. Hashing should be used as for the user PW!

2.)   The password criteria (length) for the AP (NWa110AX) are NOT the same as for an USG200Flex.

Ikarus

Zyxel_Richard

Hi @Ikarus

Also appreciate for your detail explanation.

For those two ideas, we'll have internal discussion, after that, I'll share the result with you once we have the update.

Best Regards,
Richard

Zyxel_Richard

Hi @Ikarus

For the first question, when we export the configuration file, the critical information like administrator login password will be hashed. As for the Wi-Fi password, we won't hash it: just like you can see the full Wi-Fi password when you modifying it on the web page, but you can't see the actual login password even when you changing it. 

May I know if there's any concern for a plain text? Since in most cases the network owner can decide how to distribute this Wi-Fi password, and also the configuration is only stored inside AP and applied only when booting up. So this file won't be shared to anyone else.

For the second question, could you please describe more detail about the difference you observed in the "password" criteria? (Is it the SSID password or login password? what's the difference between them?)

Best Regards,
Richard

Ikarus

Hello @Zyxel_Richard,
Many thanks for the prompt answer.

1.)

My concern for showing access keys or anything that needs to be “safe” is, that it should not be shown in a text file. It simply raises a red flag to me.
The user PW is hashed, you are absolutely right, and an admin should not see it.
But if you do backups of your config file and these files are “stolen”/hacked… etc., access to your AP’s is now possible.
It’s just another layer of security. If those config files become available to intruders your AP access points are still save. You still want to change the keys, but that’s not the first action you are doing!

BTW: One should always do backups of config files. I do it all the time and compare a “stable” saved config file with the current used file! This is a very easy and fast way to see if something “severe” has been changed!

2.)
The difference is the user PW length. I recall for USG’s a 62 character length, whereas the AP has a 32 (or so) length. Anyways, I saw at least that difference.
I hoped, that the PW policy is for all “modern” Zyxel products is the same.

Ikarus

Zyxel_Richard

Hi @Ikarus

Also appreciate for your detail explanation.

For those two ideas, we'll have internal discussion, after that, I'll share the result with you once we have the update.

Best Regards,
Richard

Ikarus

Thanks!

mMontana

FWIW i stand by @ikarus concerns about the SSID passphrase not hashed into config files.

If for any reason a config file is lost, a valuable piece of information can be retrieved, for allowing anyone to connect to wireless network, even if he/she's not authorized to.

Also, if the AP/FW appliance is not configured for wireless client isolation, knowing that piece of information may lead to traffic sniffing.

As a security concern, spreading the knowledge of the passphrase of an SSID is quite similar to have a connected ethernet port in a place where there's no access control for who's coming in and out, allowing to place a network "guest" who can lead to undesired activity on the network, which can need several hours of research and log/traffic scrubbing for find the "unwanted guest".

Moreover...

Some might say "you should not leave around a config file of your network/security device". I might agree with you. But IMVHO this kind of "flaw" is the same of one-map keys.

With this kind of keys, for a skilled enough person, even a detailed enough photo could lead the creation of an effective spare key...

So, to network admins: don't allow access to configuration backup.

And to Zyxel: please consider this kind of concerns when you design the next generation of appliances (AP controllers, Firewalls, AP's) and network devices.

Mijzelf

My 2 cents:

For one-way logins it's common that only password hashes are stored. The client provides it's password, the server hashes it using the same hashing scheme, and compares that to the stored hash. When it is equal, the client may continue. The purpose of hashing here is that even if the hash is leaked, it's not possible to restore the password from it.

But AFAIK for wifi the handshake between server and client makes it necessary that both sides have the original password, and not the hash, as the authentication is 2 ways, the client has to prove it may access the network, but the AP has to prove it is really the right AP. I don't know the exact scheme, but it's something like:

AP: I have encrypted a secret using the password + this salt. Here you are.

Client: OK, I decrypted it, and added 'Hello' to the secret, and re-encrypted it.

AP: I was able to decrypt it, and found the 'Hello'. I think we both proved we know the password. You may enter.

As both AP and client need to have the original password, it's not possible to only store the hash. It could be possible to store it encrypted, but as the encryption key should either be stored in the config too, or be hardcoded in the firmware, it doesn't actually add any security. If you really want, you can decrypt it. 

So, you shouldn't share the configuration backup with anyone which doesn't have access to the wifi network. If they have access, they already know the key.

Zyxel_Richard

Ikarus said:

Hello @Zyxel_Richard,
Many thanks for the prompt answer.

1.)

My concern for showing access keys or anything that needs to be “safe” is, that it should not be shown in a text file. It simply raises a red flag to me.
The user PW is hashed, you are absolutely right, and an admin should not see it.
But if you do backups of your config file and these files are “stolen”/hacked… etc., access to your AP’s is now possible.
It’s just another layer of security. If those config files become available to intruders your AP access points are still save. You still want to change the keys, but that’s not the first action you are doing!

BTW: One should always do backups of config files. I do it all the time and compare a “stable” saved config file with the current used file! This is a very easy and fast way to see if something “severe” has been changed!

2.)
The difference is the user PW length. I recall for USG’s a 62 character length, whereas the AP has a 32 (or so) length. Anyways, I saw at least that difference.
I hoped, that the PW policy is for all “modern” Zyxel products is the same.

Ikarus

@ikarus

For the second question, currently with the latest firmware the password length for admin is 63 characters, both on AP and Security Gateway are the same.

Thanks again for your feedback and test to our devices

Ikarus

Hi @Zyxel_Richard,
I have to come back to the user PW in exported configuration.

I have a device where is PW is not hashed. I’m not telling the model in an open forum to avoid any “hysteria”.

Pls. ping me if you like to know what kind of device I’m talking about.

Ikarus

Zyxel_Richard

@Ikarus

Thanks for sharing this information to us, I'll private message to you for getting more detail information.

Could you please explain more about the "user" password you mean: Is it the Wi-Fi password? or the admin login password?

For the Wi-Fi password not hashed case, currently it is stored in plain text in all of our models. Like I've replied in the previous post, we've made this as a feature request and will implement in the future firmware release.

As for the admin password, it should be stored as a cipher in the configuration file.

Best Regards,
Richard

Ikarus

Hi @Zyxel_Richard,
I have to come back to the user PW in exported configuration.

I have a device where is PW is not hashed. I’m not telling the model in an open forum to avoid any “hysteria”.

Pls. ping me if you like to know what kind of device I’m talking about.

Ikarus