4 ms·

This might actually be completely fixable by borrowing the trick Bluetooth-less Wi-Fi lightbulbs use for pairing. To pair, the lightbulb's ESP8266 (or cheaper

This might actually be completely fixable by borrowing the trick Bluetooth-less Wi-Fi lightbulbs use for pairing. To pair, the lightbulb's ESP8266 (or cheaper equivalent) sits with its Wi-Fi radio in monitor mode - not authenticated to anything, just watching All The Packets flying back and forth - and the smartphone sprays crafted packets to 255.255.255.255 with specific lengths (Wi-Fi encryption does not alter packet length), where the length of each packet taken in sequence then interpreted as ASCII represents the encoded setup packet containing the target SSID and password. (Of course that setup packet is plaintext and I was able to vacuum up your password *sad exploding brain* D:) Apple could do the same basic idea here: have the connected iPhone spray a magic packet sequence to 255.255.255.255, representing say an OTP-esque nonce or similar sort of thing that is communicated to the non-connected iPhone OOB (eg Bluetooth or cellular). If the non-connected iPhone can see this sequence fly past in monitor mode, then ultimately it's on the same network even if the SSID is different. ...Or at least this all works if you can associate packet X, with length Y, *with SSID Z*. If you can't localize the sequence to an SSID without being authenticated this doesn't work.

VogonPoetry 4y ago
I believe that Apple uses something similar to their "Handoff" mechanism, described in the "Apple Platform Security Guide" [1]. This uses Bluetooth Low Energy out of band paring to establish a shared key. I believe it uses the same identity keys as iMessage to establish the shared key - so you can only offer to share the WiFi password with someone you've been talking to over iMessage and you will see the name of the person you are going to share it with. Sharing the WiFi password is secure from eavesdroppers. The Bluetooth-less mechanism for WiFi only is an absolutely terrible idea and implementation. It actively leaks the network password to anyone listening. I refuse (and return) any device that requires me to connect it to my IOT network in this way. One can usually detect if this is the setup mechanism by looking at the instructions: (1) Download an App, (2) do something to the bulb (power cycles usually) (3) Setup happens automatically! I think some network stacks don't let non-privileged apps send broadcast addresses, so perhaps the scope of this damaged mechanism is limited. It is better if the ESP8266 is put into a low power Access Point (AP) mode and configure that way - but due to this (usually) not being an encrypted WiFi session, there is also a risk of leaking the network secret unless a way to do a secure key exchange is bootstrapped in the html form or API. Both of these are possible if Javascript is enabled or via an App API. The instructions for doing this might also include downloading an App, but it also ought to require finding and connecting to a setup AP first. I guess the best way to kill the "leak the password" mechanism is for a better mechanism to be created and incorporated into something like Tasmota or other public IOT ESP8266 codebase so it can be copied. [1] https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf https://help.apple.com/pdf/security/en_US/apple-platform-sec...

VogonPoetry 4y ago

I believe that Apple uses something similar to their "Handoff" mechanism, described in the "Apple Platform Security Guide" [1]. This uses Bluetooth Low Energy out of band paring to establish a shared key. I believe it uses the same identity keys as iMessage to establish the shared key - so you can only offer to share the WiFi password with someone you've been talking to over iMessage and you will see the name of the person you are going to share it with. Sharing the WiFi password is secure from eavesdroppers. The Bluetooth-less mechanism for WiFi only is an absolutely terrible idea and implementation. It actively leaks the network password to anyone listening. I refuse (and return) any device that requires me to connect it to my IOT network in this way. One can usually detect if this is the setup mechanism by looking at the instructions: (1) Download an App, (2) do something to the bulb (power cycles usually) (3) Setup happens automatically! I think some network stacks don't let non-privileged apps send broadcast addresses, so perhaps the scope of this damaged mechanism is limited. It is better if the ESP8266 is put into a low power Access Point (AP) mode and configure that way - but due to this (usually) not being an encrypted WiFi session, there is also a risk of leaking the network secret unless a way to do a secure key exchange is bootstrapped in the html form or API. Both of these are possible if Javascript is enabled or via an App API. The instructions for doing this might also include downloading an App, but it also ought to require finding and connecting to a setup AP first. I guess the best way to kill the "leak the password" mechanism is for a better mechanism to be created and incorporated into something like Tasmota or other public IOT ESP8266 codebase so it can be copied. [1] https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf https://help.apple.com/pdf/security/en_US/apple-platform-sec...