insecure WLAN-Client Configuration

[ct-open-source]

insecure WLAN-Client Configuration

[terwarf]

I would love to see an option number 4 for this:
Set a hardcoded random password in the sketch, so i can print it to a label and stick it to the device (like any router out there does).
Serial access is not always an option when the device is mounted to the ceiling, etc.

[merlinschumacher]

Hi Matthias,

thank you! :)

I know about the issue with the WiFi configuration. If I use a hardcoded key for the PSK it's more or less as insecure as before. But still better than no password at all. If I use a random key, you'll have to connect the ESP to your PC to see it, if it's shown via serial output.
The webserver is not an option as it does not (yet?) support any kind of SSL.
An alternative would be to implement WPS, as the ESP32 supports it out of the box. This seems to be the most secure way to go.

Best regards

Merlin

[mkrsn]

But whats the Problem of connecting the ESP to the PC? It has to connect to the PC anyway because the ESP needs to be flashed :) And in this case it should not be a Problem to wait a little longer (and open minicom) to get the PSK for the AP to initially configure it.

WPS may be an option but some Users (mostly geeks, Nerds i think) won't use WPS because of its "weakness". So there should be an other option to WPS - maybe a fallback.

(For example i'am unable to use WPS because it's not compiled into my AccessPoint (a gentoo Box).)

[edit]
hmm... enabling WPS is actually a security Problem because of multiple known Vulnerabilities. It should not be used.
[/edit]

[smezger]

Hi Merlin,
Hi Matthias,
A secure possibilty would bei to first have WiFi unsecured only showing a random generated password together with a reboot Button. The next start is then using the AP with this password and the user can set the WiFi credentials.
Best Regards,
Sebastian

[mkrsn]

Hi Sebastian,

and why do you think this is safe? You're willing to expose the Secret (your "random generated password") which is used for securing the following data. Every attacker which reads the "random generated password" is able to decrypt the following crypted data...

The only safe possibilities are:

• Encrypt the whole Communication from beginning (e.g. Webserver via TLS or AP via WPA2)
• Let the User hardcode the PSK (the final- or initial-PSK)

BG Matthias

[smezger]

Hi Matthias,
I see it as an more secure alternative to WPS not as an totally secure approach (that does not exist anyway). With my approach the attacker has to manually analyze the short communication where the first password is transmitted and then use this to decrypt the second communication to get the secret Wifi password. As the scenario requires that someone in the range of your Wifi captures the traffic all the time to include the short slots,a very unlikely scenario. Therefore a good trade off for me.
BR,
Sebastian

[mkrsn]

Good Morning Sebastian,

please don't take the following personally: This is exactly why IoT Devices have that rightly bad reputation (The s in IoT stands for security). Because of such senseless "Security Trade-offs", strange "security by obscurity" and so on...

Maybe the scenario is unlikely yet (i believe it's not!): But several weeks ago it was also extrem unlikely that CPU Vendors has vulnerabilities Extensions/Software in their units (for a decade). And now? Its a worst-case scenario (e.g.: Intel ME, Meltdown & Spectre) :)

So please don't call your solution "a good trade off". There are no trade-offs between security and security by obscurity - ether you do security or don't!

BG Matthias

[polygontwist]

Hi,
another (better?) way would be: Setup wired via the serial port. I have seen some projects doing this. No Wi-Fi no security problem.?.

by Andreas

[FlorianMickler]

I would welcome initial setup via serial. Somebody has some patches?

[merlinschumacher]

Hey guys,

initial setup via serial could be a possibility. I'll have to check that out. You could hardcode default WiFi data with the following code in your sketch:

iot.configuration.set("WifiEssid", "myWifi");
iot.configuration.set("WifiPassword", "myPassword");
iot.configuration.set("WifiConfigured", "True");
iot.configuration.save();

As soon as AsyncTCP and ESPAsyncWebserver support SSL we may have at least one security layer.
For now the possibilities I see to fix this properly are:

• setup via Serial
• implement WPS via push button
• create a truly random WiFi password for the AP and print it to serial after the first boot

[Dirk007]

create a truly random WiFi password for the AP and print it to serial after the first boot

--> https://github.com/merlinschumacher/Basecamp/pull/22/files

[mkrsn]

We're talking about the initial Setup of a new Device and not about prepared devices.

You have to upload your sketch via serial to a new ESP32 (initial Setup). Why is Serial Access in this moment not an option?

[terwarf]

@mkrsn that's not a problem at all. The problem is you can reformat the flash (reset 7x), so the initial created password is lost. That's why i would prefer to generate the password myself and keep it in program memory. So a user i hand the device is not able to brick it with just pushing a button a couple times ;)

[merlinschumacher]

The AP is now optionally encrypted. See the example for details.