Almost every ESP32 device is left unattended while storing the owner's wifi credentials.
You can't exactly make a wifi doorbell, or wifi thermostat, or wifi lightbulb, or wifi security camera, without storing a wifi password.
Of course, a cynic would say product manufacturers deploy these features hoping to protect their source code, rather than to keep the customer's wifi passwords safe.
Not sure if supported by the ESP32, and it's kind of complex to setup, but I think you could set up a per-device password, with WPA enterprise (PEAP/MSCHAPv2), and a RADIUS authentication server.
What you want to do with that is another question. You can't really do anything against someone who decides to fake your thermostat reading, but having access to the hardware already defeats that.
At least you limit the impact to the one device that was stolen. Having someone check that the device is still there could be helpful. And since that attack still takes some time to perform, some monitoring could detect that the thermostat/etc hasn't been connected in a while.
I am not sure how useful extracting a Wi-Fi password that's only used by the doorbell would be?
What I am thinking of doing for the outdoor weather station I will someday get around to finishing is to have it be on a separate WiFi network. To get data from it you will have to connect to that WiFi network.
Inside the house, I'll have an RPi or something like that which has WiFi and Ethernet that will use its WiFi to connect to the weather station's network and Ethernet to connect to my home LAN.
If someone steals the weather station, the only password they get is the password to the weather station network, assuming that it has one (not sure yet...may make it open so that anyone in WiFi range can connect and read the data).
Same thing for the automatic wildlife camera I'm contemplating. Probably that will go on the same WiFi network as the weather station.
I do this for my cameras (no traffic out from the VLAN, but allow connections in from the NVR machine) and IoT devices (traffic to the internet is allowed, only some traffic to my other networks is allowed). It works very well.
I use Unifi for my networking gear, but I've done the same thing with DD-WRT on an Asus router/AP device.
Sure you could. It would just require the access point to provide a passwordless guest network for such devices to use, and then encrypt the traffic end to end for the actual security.
Maybe you assume that's okay, but it's an attack vector on the server, and it means someone can emulate a device that isn't really one.
The attacker would have to extract the UUID from the device it wanted to impersonate, which still wouldn't allow it to impersonate any other device the same way a WiFi password does, and would then be detectable because there would be two devices claiming to have the same UUID, at which point you generate a new one for the real device after addressing whatever allowed the attacker to extract it to begin with.
A) routers must support network isolated guest network
B) anyome can connect to my internet to download stuff
C) if my compuer and IoT hub is on my main network, and the lightbulb is on the guest one, how do they talk? Through the third party server? What if there is no internet, I can't control my lights?
The actual solution is to have individualised passwords for each device that can be revoked, isolated, etc. Those features are not found in 'normal' wifi routers
> Those features are not found in 'normal' wifi routers
Then deplore the state of current consumer wi-fi routers and protocols. We can do better than this.
More to the point, Wi-Fi wasn't really designed for this, so maybe a new kind of extension is warranted (like NAN, P2P, mesh, etc). Or use another protocol: Zigbee, Lora, z-wave, etc. These generally have the guarantees you want, sometimes do mesh networking, etc.
In the past, I've used a raspberrypi3 as a "IoT hub", using its wi-fi network to connect "smart" devices. The third-party server was my hub. Everything works without internet. The dedicated wi-fi network doesn't have internet. You can even lower the bandwidth to 20 MHz, and 1Mbps to achieve greater ranges on that channel.
If your IoT devices aren't on the same subnet as your smartphone or computer, the vast majority of their "frontend apps" are already DOA. If you're lucky, those apps might let you explicitly specify the device's IP address (in a half-baked fashion that still doesn't work very well).
There is a tradeoff for letting users run their own code on these devices: people other than the device owner may be able to run code on them too.
Obviously you wouldn't want to have to type in a password or use a secure card to turn your lights on.