Myths of Wi-fi Security

Computer Security, Cyber Security 1 Minute

I found the article 5 Wi-Fi Security Myths You Must Abandon Now interesting, particularly in the context of doing the security basics right.

In summary:

  • Myth No. 1: Don’t broadcast your SSID
  • Myth No. 2: Enable MAC address filtering
  • Myth No. 3: Limit your router’s IP address pool
  • Myth No. 4: Disable your router’s DHCP server
  • Myth No. 5: Small networks are hard to penetrate

Certainly the first two are commonly suggested as good practice, but the article puts forward the case they are all but useless. The demonstration given to recent IISP East Midlands – Cyber Attacks & Live Hacks emphasised this.
In the blog Design for the novice… it is argued that to provide a secure-by-default solution configuration choices like these should be left to experts.

Do we as an industry risk creating the impression of security by offering options such as “hide SSID”, whereas the true expert recognises them as useless?

Advertisement
Published

2 thoughts on “Myths of Wi-fi Security”

  1. I also saw the article a while back; I’ve never employed Myths 1, 3 or 4 (1 owing to familiarity with Kismet), but for some wireless routers, I do think 2 still has value, even if only as a cause of sufficient inconvenience to an attacker that, unless they’re after your wireless router in particular, they’ll go and look for an easier target further up the road.

    I think the question you ask is a very interesting one. My current view is that “the tail wags the dog” to a degree; if a security researcher, having found a weakness, suggests a mitigating capability, or one vendor introduces a feature (which may or may not be spurious) and that capability or feature finds its way into a policy or other requirement set for an influential customer as a result of their CSO / CISO / CTO keeping current on news and research, then other vendors will follow suit by introducing the feature to “get the same tick in the box” and not be excluded from competitive consideration by the feature’s absence.

    It’s a rare event that requirements get deleted from policies (bureaucracy makes it relatively easy to get a requirement into a policy, compared to the effort needed to get it taken out), thus the perceived need for the feature gets perpetuated, even if the world moves on and the feature is no longer useful.

    Probably my favourite example of this to cite (and least favourite to have to implement), involves anti-virus. I take a strongly Darwinian view when it comes to viruses, and yet some significant customers still require anti-virus solutions to be implemented on platforms for which there aren’t viruses. I could readily have a rant about this here, but it’s your blog, so I’ll spare you ;-).

    Like

  2. Hi Colin, I didn’t read the mentioned article before. But now I would like to read this. By the way, As I’m a computer engineer, I believe myth no. 2 that is enabling mac address filtering should get some value, it still is important for wi-fi security…

    Like

Comments are closed.