4 ms·

One negative side-effect of the same SSID policy is you might not be able to share your WiFi password by simply putting your devices close to each other. Ordina

One negative side-effect of the same SSID policy is you might not be able to share your WiFi password by simply putting your devices close to each other. Ordinarily, Apple devices can share WiFi password easily by putting an already set up device close to a new one. But if they are momentarily connected to different networks (frequencies), even though they have the same SSID and same password, Apple software will see them (correctly) as on two different networks so the password will not be shared even when the password is the same on both networks. I don’t know if the automatic band switching is any better than the manual one but I find this issue is quite a hassle.

gruez 4y ago
>But if they are momentarily connected to different networks (frequencies), even though they have the same SSID and same password, Apple software will see them (correctly) as on two different networks so the password will not be shared even when the password is the same on both networks. I don't get it, how is this an issue? If both devices are already connected to the same SSID, then both devices already have the password. Why would you need to share passwords?
- jzwinck 4y ago
  One is connected and logged on. The other sees the same-named network and is not logged on yet because it doesn't know the password. Two different senses of "connected."
- woqe 4y ago
  Multiple non-unique SSIDs (name) can exist within a single router. More extremely, you and your neighbor can have the same SSID on two different routers.
exikyut 4y ago
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...
zinekeller 4y ago
> One negative side-effect of the same SSID policy is you might not be able to share your WiFi password by simply putting your devices close to each other. It seems that my experience is vastly different from yours, although I've encountered a bonkers router that separates 2.4Ghz and 5Ghz into different subnets or isolates them in such a way that only other 2.4Ghz/5Ghz devices see them so I'm not dismissing your experience completely.

gruez 4y ago

>But if they are momentarily connected to different networks (frequencies), even though they have the same SSID and same password, Apple software will see them (correctly) as on two different networks so the password will not be shared even when the password is the same on both networks. I don't get it, how is this an issue? If both devices are already connected to the same SSID, then both devices already have the password. Why would you need to share passwords?

jzwinck 4y ago
One is connected and logged on. The other sees the same-named network and is not logged on yet because it doesn't know the password. Two different senses of "connected."
woqe 4y ago
Multiple non-unique SSIDs (name) can exist within a single router. More extremely, you and your neighbor can have the same SSID on two different routers.

exikyut 4y ago

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...

zinekeller 4y ago

> One negative side-effect of the same SSID policy is you might not be able to share your WiFi password by simply putting your devices close to each other. It seems that my experience is vastly different from yours, although I've encountered a bonkers router that separates 2.4Ghz and 5Ghz into different subnets or isolates them in such a way that only other 2.4Ghz/5Ghz devices see them so I'm not dismissing your experience completely.