What are the connectivity implications for implementing a hidden Wireless SSID?

I had problems with a D-Link router where I had hidden the SSID when I brought home my first Vista laptop. Every day I had to add the network, and then the next day it wouldn't find it again and so on and so forth. So I googled it. One of the things I found is an argument that not only is "hidden SSID" not even a minor security improvement, its actually a big security problem.

Here's the content from http://technet.microsoft.com/:

Why Non-broadcast Networks are not a Security Feature

Wireless security consists of two main elements: authentication and encryption. Authentication controls access to the network and encryption ensures that malicious users cannot determine the contents of wireless data frames. Although having users manually configure the SSID of a wireless network in order to connect to it creates the illusion of providing an additional layer of security, it does not substitute for either authentication or encryption.

A non-broadcast network is not undetectable. Non-broadcast networks are advertised in the probe requests sent out by wireless clients and in the responses to the probe requests sent by wireless APs. Unlike broadcast networks, wireless clients running Windows XP with Service Pack 2 or Windows Server® 2003 with Service Pack 1 that are configured to connect to non-broadcast networks are constantly disclosing the SSID of those networks, even when those networks are not in range.

Therefore, using non-broadcast networks compromises the privacy of the wireless network configuration of a Windows XP or Windows Server 2003-based wireless client because it is periodically disclosing its set of preferred non-broadcast wireless networks. When non-broadcast networks are used to hide a vulnerable wireless network—such as one that uses open authentication and Wired Equivalent Privacy—a Windows XP or Windows Server 2003-based wireless client can inadvertently aid malicious users, who can detect the wireless network SSID from the wireless client that is attempting to connect. Software that can be downloaded for free from the Internet leverages these information disclosures and targets non-broadcast networks.

This behavior is worse for enterprise wireless networks because of the number of wireless clients that are periodically advertising the non-broadcast network name. For example, an enterprise wireless network consists of 20 wireless APs and 500 wireless laptops. If the wireless APs are configured to broadcast, each wireless AP would periodically advertise the enterprise’s wireless network name, but only within the range of the wireless APs. If the wireless APs are configured as non-broadcast, each of the 500 Windows XP or Windows Server 2003-based laptops would periodically advertise the enterprise’s wireless network name, regardless of their location (in the office, at a wireless hotspot, or at home).

For these reasons, it is highly recommended that you do not use non-broadcast wireless networks. Instead, configure your wireless networks as broadcast and use the authentication and encryption security features of your wireless network hardware and Windows to protect your wireless network, rather than relying on non-broadcast behavior.

In my experience, the most common problem for connectivity issues against hidden SSID's is typos in the client connection config. Case-sensitivity is usually my culprit.

This is a hardware issue (or a software issue with some hardware vendors). I've suffered this problem on my wireless networks. I too run one of my wireless networks with a "hidden SSID" and have had some issues with it. I know for a fact that our older G4/G5 based Mac OS X machines will not stay connected to a hidden SSID network. I've also experienced the problem with some older Linksys wireless cards on various versions of Windows. Other cards and PC's have no problem with it. I've got several machines that have worked flawlessly on it without a hiccup. Most of these are newer machines from Dell or have newer wireless cards including newer Linksys cards (which leads me to believe it's probably a wireless chipset issue but I don't have enough to prove it).

It may not have to do with the SSIDs at all. You may want to take a look at the wireless controller itself. At one place I worked we ran two wireless networks from the same controller, one for guests and a secured one for users. What we found was that there would be random losses of connections or, at times, one of the networks would disappear. Eventually, we gave each network its own dedicated controller and the issues were resolved. Granted, this may not be the optimal solution, but it may be something you would want to look into.

Making an SSID "hidden" just prevents it from being broadcasted in the beacon; so I would expect no connectivity problems.

Check for possible sources of interference, try changing channels, etc.

Leaving the whole Security by Obscurity speech to the side... what happens if you uncloak the SSID long enough to use it for however long it usually takes for the clients to have connectivity problems? If it works fine when unhidden, but has problems when hidden, you have your culprit. If you still have connectivity issues when unhidden, then your problem lies elsewhere.

A "closed network" means that the SSID is not included in the beacon frames. Beacon frames are still sent periodically because they're important for the operation of the network, so you won't see any changes in the amount of traffic or in any performance aspect of the operation of an 802.11 wireless network.

From a security standpoint, the SSID will still be visible in probe requests and association requests, so it's not much of a security feature. But because you're talking about using it for your network admins, I think it's a decent usability choice--you are keeping your normal users from seeing one more option in their list of wireless networks that they could associate to.

As others have said, one downside is that people have to remember exactly how to type it. With older version of Windows and some driver software, if you type in the name of an SSID that doesn't exist, you'll end up creating an ad-hoc network with the mistyped name that other users might try to join, which gets you back to having end users who are trying to join the wrong network.

I suppose some older drivers could have trouble associating to networks with hidden SSIDs, but that "feature" of 802.11 is really old, so I would be surprised if it actually caused connection problems.

Each additional BSSID you add (which is how most modern APs and controllers create new SSIDs) will add some amount of overhead in beacons and management traffic to your network regardless of whether the SSID is advertised or not. If you can accomplish some other way of giving admins the extra access they need (RADIUS-based VLAN assignment, role-based policy enforcement on the controller, etc.) without creating a new SSID, you might think about that. But there probably won't be much difference in practice.

Some special-purpose instruments and embedded systems show all "available networks" via a list of broadcasted SSID, however they are now more and more few and far between. I think the only other thing to consider is what was mentioned above, about checking for interference and maybe doing a scan of all wireless networks in the area for possible overlapping. With hidden SSIDs you may never have a networked company XBOX360, that's for sure ;)

I would question what security benefit is gained from hiding the SSID beacons, in lieu of the headache posed by badly implemented clients.

All data from authenticated clients is still passed over the air with the SSID stamped in plaintext. These identifiers are likely to be seen by a third-party taking more than a glancing look at secured networks in the area.