0

I suspect that an android device is trying all SSIDs it was ever connected during wifi scan. 1) It alone gives enough information to identify the device 2) If a network with no encryption is saved, a MitM attack can be performed.

Is there a way to handle it? E.g. trying only networks that are in the range (listen for beacons). It will make impossible to connect to hidden SSIDs, but who uses it?

  • Disable Wi-Fi, unless you are at home with secure network. And generally, open networks are dangerous. – Alex Cohn Nov 11 '17 at 17:28
2

I suspect that an android device is trying all SSIDs it was ever connected during wifi scan. 1) It alone gives enough information to identify the device 2) If a network with no encryption is saved, a MitM attack can be performed.

This would be typical of most mobile devices if you store the connection in a way where it will automatically connect again at a future time.

Is there a way to handle it?

Yes. You can do so by doing whatever combination of the below you like. This will at least limit your exposure.

  • Don't store you wireless networks so you can connect automatically in the future.
  • Delete wireless networks when you are done.
  • Disable wireless on your device when you don't want to be connected.

E.g. trying only networks that are in the range (listen for beacons).

In comments elsewhere, you seem to find "passive scanning only" as an appealing solution. This will significantly increase times for a device to connect to a wireless network (from your reported 3+ seconds to something more like 6-20+ seconds) and have the potential to create what appear to users as "outages" of similar periods every time the device scans to check for better networks to which they can roam.

Put simply, it won't happen. Why? Because it is asking for developers to add a feature that (a) decreases usability by increasing time taken to find/connect to networks and (b) impacts modern devices more significantly than legacy devices. Or put another way, how many users do you think would be pushing developers to "significantly increase the times it takes to connect to a wireless network"?

Automatically trying to connect to any configured SSID as if were hidden was a change made to simplify the user experience and make it easier for the masses. As in many such feature decisions, this does come at a cost for potential security/privacy issues. You will find little support in developer circles for going back on this decision and increase the number of [confusing] choices people [with little technical knowledge] need to make when connecting to a wireless network.

A better and more likely suggestion that you could make is an option (global or per profile) to "allow connections to hidden networks" that would be enabled by default and provide the existing behavior. Knowledgeable users could then choose to disable it if they wanted, and the active scanning for networks taking place could do so without including an SSID. No negative impact from disabling active scanning necessary.

Still a tough sell since there are many features users [in larger numbers] want for their devices and developers tend to follow the demand, but more viable than the prior suggestion.

It will make impossible to connect to hidden SSIDs, but who uses it?

Many organizations do and some home users. Personally I find very few cases where it is used for a valid reason, but my opinion doesn't stop people from using hidden SSIDs.

  • "but who uses it" means there may be an option for a feature which has more privaca but don't allow users to connect to APs with hidden ssids and many users can use it. I personally never had to connect to an AP with hidden ssid. – Smit Johnth Jan 11 '18 at 14:43
  • the device scans to check for better networks to which they can roam. - yes, roaming may be a problem too if scans has to be made on other channels since waiting on another channel means temporary disconnect. – Smit Johnth Jan 11 '18 at 14:46
  • easier for the masses - well, I never claimed it would be a solution for every housewife. That's why I spoke about an option. – Smit Johnth Jan 11 '18 at 14:47
  • Just because you haven’t used a feature is immaterial. You probably haven’t used the majority of features in your devices/software, yet there are many people who do. You are asking for a feature to be developed that is moving backwards (geared for older tech and reducing usability). You are never going to get traction for such a feature unless you code it in yourself, but it will never hit mainstream distribution. I offered an alternative giving a solution for what you want and which doesn’t move backwards, yet you still seem to want to argue for your flawed solution. So done here. – YLearn Jan 11 '18 at 18:09
  • Nice try to teach me, but 1) I almost never seen hidden SSID's being used, 2) they has no security meaning. I know it will never be implemented just because noone gives a shit if users can be tracked. How many manufacturers have implemented MAC change? Well, your "solution" is even less usable. – Smit Johnth Jan 12 '18 at 17:55
0

The proposed solution will not work since the attacker is sending out malicious beacons.

In Android you can forget networks that don't have security. Don't know if you can do this automatically. On my one plus there is no option to not remember networks. Maybe there are apps that can do this for you.

  • It could work against leaking of identifying information. – Smit Johnth Sep 12 '17 at 13:58
  • Sorry, misunderstood. It would require to change the driver that sends out these beacons. So it's not something you can do easily. Also, take into account the frequency of these broadcasts from the access point. It might take much longer for a device to connect if you rely only on these broadcasts. – Silver Sep 20 '17 at 9:23
  • Beacons are sent at least 10 times per second. I don't think it will be a big loss. – Smit Johnth Sep 28 '17 at 11:35
  • @SmitJohnth, you might think 100ms isn't long, but the reason passive scanning is considered inefficient is that a client needs to scan every channel and typically wait at least 100ms (up to 200ms to cover longer beacon intervals) to ensure it has found available APs. If you take the US and exclude DFS channels, you have 26 channels which gives you nearly 3-6 seconds of scanning time. If you include the DFS channels or in a different region, this number can easily climb upwards to 10+ seconds before even establishing a connection. Bad enough when connecting, but when the client wants to roam? – YLearn Oct 12 '17 at 19:07
  • @YLearn how have you got 26 channels? 3+ seconds is typical connect time on my android device. Can't say anything about roaming, never used it. At least my suggestion can be an option. – Smit Johnth Oct 27 '17 at 20:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.