Based on what I read on one of their FAQs, it is not as good as a secure enclave, but it is quite a bit better than simply not providing a show password option.
The password is not stored on the devices of the people you share with. It's stored on Microsoft servers. When the device someone you have shared with notices that a network you've shared is available, it gets the key to connect, then presumably forgets it.
I wonder if it is possible to do better? The idea would be that when setting up the connection (so, setting up session keys and authenticating) the device could pass these packet through to Microsoft's server. Microsoft's server could then calculate the response packets and give them to the device to relay to the access point. When the connection set up is all done, Microsoft's server could pass the session key to the device, and subsequent packets would be handled entirely on the device.
There are two (at least) things that could torpedo this kind of approach. (1) the protocols might work in such a way that you cannot hand off the setup/authentication, or they might require frequent enough re-keying that spotty cell access could prevent keeping wifi working, and (2) the connection setup and authentication might be handled in firmware that does not provide a low enough level interface to do the fiddling needed.
The WiFi password will be there in any case, obfuscating it is not a big hurdle, and asking a secure element in a $30 lightbulb is unreasonable in a world where many PC still ship without a TPM chip.
People sure should have a dedicated IoT network, but in the grand scheme of things, home networks are not usually that sensitive, as in no important yet unencrypted service will be exposed internally as it is typically the case in enterprise networks.
> You can't exactly make a wifi doorbell, or wifi thermostat, or wifi lightbulb, or wifi security camera, without storing a wifi password.
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.
It should be trivial to make the password write-only to the wifi electronics. For an attacker to get the wifi password, you'd have to remove the controller, and the controller could even be designed to mitigate against that attack too.
> You can't exactly make a wifi doorbell, or wifi thermostat, or wifi lightbulb, or wifi security camera, without storing a wifi password
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.
who says they need to use wifi. i expect a significant proportion of those passwords are shared with other systems, or may allow access to other corporate services - most likely VPN.
Please, please, can we have the same for WiFi?! Trade a key with the AP when you first associate, and be done with it. The entire concept of a WiFi password is a *%^$ waste of time.
So, a reasonable person (maybe not from here) would ask themselves why the lightbulb has a secret password to access the Network. After all we want the Network to be ubiquitous, so why is there a password anyway? If there wasn't a password then bad guys couldn't find out what it is. (You may think, aha - but with ubiquitous access they wouldn't need to, but as we saw for SSH shared passwords mean that getting a password may be _more_ not less valuable than access to the thing it was protecting).
It turns out that besides the stupid sociological reasons (which also result in us trying to make it impossible to sleep on a park bench rather than providing people with homes so that they won't _need_ to sleep on a park bench) there's a technical reason, and maybe that we can fix.
WiFi (802.11) has traditionally been plaintext out of the box. So every participant can see everything sent and received by every other participant. If you have a password this isn't so. Thus, a WiFi network plus a billboard announcing the WiFi password to everyone in the neighbourhood is actually slightly _more_ secure than one with no password at all.
Finally in WPA3 this is fixed, participants with passwords use a PAKE but everybody without a password gets OWE (RFC8110) to secure their network access. Since they don't have a way any way to authenticate they can be MITM'd of course, but you can't just passively decrypt everything they're sending and receiving. So a WPA3 era WiFi network that's "open" to everybody is protected better than your WPA2 PSK "ThanksMike" password for Mike's Coffee Shop.
That was my first thought as well. Simply removing your WiFi password can have unintended consequences, especially for people with little technical skills.
> you probably shouldn't leave a sensitive device unattended anyway
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 a viable option, this would allow anyone to intercept traffic.
(To be fair, a lot of wifi routers are broken and will forward you all decrypted traffic from other users anyway on request. Try running WireShark on public wifis.)
The big problem is that Wifi with no password provides no privacy. Ideally we would have a wifi mode that is encrypted, but does not require a password. Just like Https.
I put all untrustworthy devices on my guest WiFi. My game consoles, e-readers, streaming devices, and Internet appliances don't need access to my privileged network, and they don't need access to each other. And if I were so inclined to buy smart bulbs, they'd get the same treatment.
And, yeah, my guest WiFi password is kind of secret, but I routinely give it out to people who I only casually trust.
If you're running an actual corporate network then a wifi password had better not be the sum total of the protection.
For home use - who cares? It would be a sizable mission to make use of the password...and that would get them what? A couple of lolcats and my skyrim saved games? Nice.
No way. “password” protects me from the neighbor torrenting movies or Googling bomb recipes or whatever, which is the bulk of the threat model for residential Wi-Fi.
It shouldn’t be practical, that’s by design. Imagine if every captive portal had you install their root certificate to access the WiFi, with just the click of a button.
Or i could just dump a Raspberry Pi Zero W attached to a 10000 mAh power bank in your garden, and wait for it to capture a 4 way handshake. Retrieve the data from the Pi, and throw some serious cloud computing power at it while bruteforcing the password.
Granted, it's going to take longer (perhaps), but chances are you'll never notice until it is too late. Of course, most users won't notice new devices on their Wifi anyway.
People keep forgetting that Wifi is per definition insecure. It's not a point to point technology, and every single packet you send is broadcast in a wide area around you.
Furthermore, all current authentication methods, WEP/WPA/WPA2 (excluding WPA3 for now, as it has yet to see wide adoption), have all been cracked in one way or another.
I'd rather just delete the password. Or better yet, skip the wifi bulb and use something like Z-Wave or Zigbee.
reply