Ok, so I'm getting in a dorky debate with someone on Twitter (ugh, that's something I never wanted to say). I read his review of some product that didn't support hidden SSIDs, and the reviewer cited this as a giant security flaw and docked points from the product.

I wrote to him to argue that because it is so trivial to get around hidden SSIDs, it's not a worthwhile security practice. In fact, I'd argue that a novice computer user might erroneously assume that if the SSID is hidden, they don't need to use security and can therefore forgo using a password, which would be a big mistake.

He wrote back with the following: "It's standard practice. Of 100s of tested devices this yr alone, only 2 didn't support it. Must cover every base for security."

I argue that it is NOT "standard practice" at all. A simple search for "hidden SSID" will give you hundreds of results that say essentially the same thing: getting around hidden SSIDs is laughably easy. And while I might agree that it's strange that this product didn't include support for it, I wouldn't dock them for it.

Still, he seems to be insisting that hidden SSIDs are some sort of pillar of network security. My analogy for him was that a hidden SSID on a network with WPA2 AES was like a bank using a blanket to cover their locked vault. Everyone knows that the vault is there, but few people could get in there once they push the blanket away.

What say you guys? Am I off base here?

Standard practice to include it, not standard practice to use it as security.

I agree with you. It adds little to no security to a Wifi network.

If someone is determined to hack in, it will do nothing. However, it probably *will* prevent the casual neighbour next door using your Wifi. Not someone hacking, just someone from "leeching" off your Wifi.

Not really a security feature then in my mind. If it needs to be secure then use one of the proper authentication/encryptions mechanisms (which you should be using regardless).

I suspect you will not get someone like this to back down since he thinks he knows all.

Does he also dock points for *supporting* WEP since that has known and fairly easily defeatable security flaws? His original logic should apply here.

I agree that hidden SSIDs are not a barrier to penetration. In much the same way that MAC address filtering doesn't protect your network either, because it's so easy to spoof a MAC address. Anyone trying to actually penetrate a network would get past both of those things fairly quickly. They're tiny little things which result in requiring an extra step to connect.

In fact, for normal legitimate users trying to connect to a router on a simple network (like a home or a small business), they often add a level of complexity to connection which causes additional tech support hassles for the owner of the network. I would argue against them being Standard Practice in those simple cases. I'd say that anyone who is blindly hiding their SSID, or MAC filtering, because they think it improves security, without thinking about why, is going about security in the wrong way. Your point that the feature can be dangerous, for that reason, is well taken.

But... There are important reasons for those features to exist, some of which I think are actually standard practices. More on that below.

First, one quick aside: Since those features are standard features on a router, I would definitely dock the manufacturer points in a product review for not including those features. I'd wonder what else they left out, under the hood, when they decided to exclude such common features. It would call into question their development and QA practices, and I would have trouble trusting a router whose firmware left those things out.

But that's not the argument you're making. You're arguing that SSID hiding isn't a standard security practice because it's useless for security. Maybe the SSID hiding doesn't increase the security, but it can be an important part of a larger network security plan. There are legitimate reasons besides security that someone would want to use that feature.

For example, hiding some of a company's SSIDs in a large company with a complex network would clean up the list of available SSIDs for those connecting to the visible networks, and make it easier to select the correct SSID. Imagine a company where the hidden SSIDs were only meant to be connected to by a subset of computers who had been set up with a particular group policy or a particular set of distributed WLAN profiles. The idea is that those computers' users are never expected to have to type the SSID or its password, they just run the group policy or the WLAN profile to connect. In that case, you could use the SSID-hiding as a way to automatically filter those special GP-only networks out of the list of available networks. That way, the PEBKAC users and guest users trying to connect to the regular, visible networks by hand, aren't calling up tech support and asking why they can't connect to the GP-only SSIDs. I suppose from that point of view, you could say the SSID hiding *is* related to security... it's just one of a *set* of important features that allows you to cleanly tier your network access. It doesn't make those routers any more secure, but it's an important part of the larger overall network security policy.

Similar thing with MAC addresses. Our company recently implemented MAC address filtering on our network. Each AP has a highly secure password and is using the latest security protocols already, but they are also MAC filtered. Before you can use one of the AP's, you must first connect via either the wired network, or via another PC which is already connected, and then you must fill out an internal web form with your MAC address, and specify which networks you want to connect to, and what your purpose for connecting is. And then you must wait for IT to add your MAC address. I needed to get something on the Wlan last Friday and couldn't, because IT was on an offsite meeting and wasn't answering those requests. Wow, what a pain! And a management headache too: I asked the IT manager why on earth would he cause himself and his users such a massive headache for zero security benefit. He had an answer similar to the one above: The MAC filtering wasn't a way to prevent access, it's simply a convenient filtering method that allows them to keep organizational track of which users are requesting access. Then be able to track which addresses are being used for what, so they can match things up if something goes wrong. I *get* this. Even though MAC address filtering would be completely useless on my home network because it doesn't help actual security and just makes things hard when I have guests over, I could really see this helping an IT guy keep his user base organized at a large company.

I'm sure there are other legitimate reasons for using those features, even if, when taken by themselves, the features aren't secure on their own. Some of those reasons could likely be considered Standard Practice as well.

Finally, keep in mind that twitter limits your ability to explain your answers. 140 characters ain't much. Perhaps the person you're arguing with simply isn't able to be as nuanced as I was up above, and has to oversimplify his answers, to fit in the limited space.

Now, thinking back on what I wrote. I'm curious which product this was. If it was a super-cheap little router that was entirely meant for home use, I could almost understand why they would deliberately leave out features which are complicated and confusing for home users. Most home users need the SSID to be visible, and the act of hiding the SSID would be like shooting themselves in the foot... Any home user advanced enough to legitimately need to hide his SSID can bloody well put DD-WRT or Tomato on there.

So yeah, I see a difference between the Home/SOHO situation and the corporate situation. Arguing that SSID hiding is a baseline requirement for every router?... maybe not so much.

My two cents:

If you care about security at all, you do WPA2. Anything else is meaningless. Hidden SSIDs are just an opportunity for a usability fail. ("Hey, I can't see your network. How do I get on?")

Was this device by any chance the Wink connected home hub, and was the review by any chance this one? I just happened to be looking into that device this weekend and noticed the same thing. I ended up not buying one for reasons totally unrelated to the hidden SSID thing (agree with Dan and others that hidden SSID is more of a liability than any kind of security feature) but did notice that very strange litmus test was so integral to the mediocre review.

If that's the one, then it's a different thing than what I was thinking. I initially thought this was about a product review of a Wifi router which can't hide its SSID.

But if it's really about that "Wink" thing, then that's a different deal: It's a device that is expected to connect *to* a Wifi router, and if the router's SSID is hidden then it won't work.

Looking at the thing, it looks like it's designed mainly to be used with the little "magic button" connect method, aka "WPS" (WiFi Protected Setup). I wonder, does WPS itself even support hidden SSIDs? In other words, if I have a router with a hidden SSID and some WPS-capable device other than the Wink trying to connect to that router, and I press the magic button on both of them, should I expect them to pair up? Or should I expect the pairing to fail because the SSID is hidden? My googling isn't coming up with immediate answers to that question.

If WPS supports hidden SSIDs, yet this little "Wink" thing doesn't, then fuck 'em, zero stars review. This is a product that's meant to CONNECT EASILY TO OTHER PRODUCTS. That's the point of the thing. It's Wink's fault if that doesn't work. There are legitimate standard-practice reasons to hide an SSID (even if hiding doesn't prevent penetration), and it's not up to Wink to force someone to unhide their SSID and change their network organization just so their little POS will work. Jesus, just fix it, guys.

If WPS doesn't support hidden SSIDs to begin with, then it's not Wink's fault, my review would mention the limitation but it would not dock them any stars for it.

Hidden SSID violates the 802.11 spec. 802.11i (WPA2) even states a client may refuse to communicate to a base station hiding the SSID.

If the WPA2 spec calls it out like that, then it's clearly an expected feature of the base stations. Saying that a client "may" choose to refuse to communicate with a hidden SSID doesn't mean that it's good product design to do so.

I'm having a hard time parsing this, and should probably clarify my comment based on what I've seen:

802.11 base spec states the need for a beacon frame to be sent from the access points for various reasons. Part of this beacon frame is the SSID.

Some vendors decided to allow that SSID to be set to NULL instead of the actual network name, thus becoming the "hidden SSID" option so many access points have. This turns off one, of I believe five different frames that have the SSID in them. Problem is when this is turned off on the access point, clients tend to broadcast the SSID in the clear to try and find the access point. Buggy behavior in this situation with Windows XP (pre WPA2 patch) led to the "Free Public Wifi" propagation issue (also tied to a bug where Windows would create an ad-hoc network on it's own when it couldn't find the base station).

802.11i further clarified how the beacon frame needs to be handled. This included the need for the SSID in the beacon frame to match the SSID in other types, as per the handshaking that happens to make WPA2 secure. This comes into play mostly in multiple access point environments, to allow clients to roam securely without a full disconnect and reconnect during every roam.

The "may" choose to refuse to communication statement seems to be in there as a warning that equipment following the spec fully may programmatically choose to not communicate, due to mismatching SSID info being sent in different frames (NULL vs the actual name).

802.11n had some additional clarifying language added.

I should probably get back to work though instead of looking at 802.11 tech spec documents. They are very dry and hard to parse at times. And definitely wouldn't fit into 140 characters to win some twitter fight.

Reminds me of:


Permanent link to this comic

Many times it is just not worth arguing with some folk, life is too short.

Totally true, but sometimes it's fun In this case, I'm working on whether I think I'm right just as much as I'm trying to prove that he was wrong.


Haha! You nailed it! That's exactly what I was looking at. I'm trying to keep up to date on all the different home automation systems out there, and I was considering picking up a Wink hub to test it out.

Tony F: thanks for some really great thinking on this subject. I hadn't thought about the corporate use of hidden SSIDs as means of simply managing a large number of names. That's a cool idea.


Frankly, I can't argue with that, but I still don't think it should be weighed so heavily in a review.

I should point out, but the way, that WPS is insecure, and I'd include that in your proposal to dock a product if it supports MAC address filtering

FWIW, I did find that WPS push button setup does require SSID broadcasting to function. Without it the process wouldn't work, as the client wouldn't know the network name to join to continue the next WPS setup step.

I suspected that might be the case. It's not the Wink's fault, then. WPS pushbutton setup requires it.

Where did you find it? He could win his argument with that link.

Probably not. He'd most likely come back saying that they shouldn't set up the device that way. I actually agree with that, since WPS is insecure.

I should clarify: I'm not defending the Wink product. I don't care one way or the other about it, and in fact I decided not to order one because it didn't support all the devices I need it to. If they add my ZWave remotes in the future, I'll give the product a try.

So your issue is unrelated to whether the product supports hidden SSID's. Your issue is entirely with his statement, in the review:



Then taking that statement by itself, unrelated to any product...

You're right, it's bullshit in this day and age. In fact I'd go so far as to say that the opposite is true: For the types of hackers who are most likely to actually attempt and/or succeed at hacking into your wireless access point, hiding your SSID might entice them more.

I can't think of any good reason for any home network to hide its SSID. Doing so does not improve security and merely makes it a pain in the ass to get new devices connected to it.

Saying that it's standard practice to hide SSIDs is a true statement. There are plenty of installations out there that hide their SSIDs. But often they're doing it because they incorrectly believe it will improve security. Statements like the one in the review are helping to spread that misinformation and keep that falsehood alive in the public consciousness.

Simply rewording that line in the review, to say that the product doesn't support hidden SSIDs, and that's a problem because some networks have hidden SSIDs on purpose, would make the review accurate without spreading misinformation. But clearly this guy doesn't actually understand network security, so you're not going to convince him to change his review.

I'm no security expert either, but I understand enough to know that hidden SSIDs are not valid as a security layer.

Looking back on the statement in the quote, though, there is one way you could take that statement which absolves him of any responsibility. I don't think he wrote it with this intent, but a literal interpretation of the actual words would actually be a true statement. The statement doesn't say "I recommend...", the statement says "It's recommended that...". Which, if you interpret it super-literally, can be considered a true statement: Some people do actually recommend that. Misinformed people who don't understand network security do actually recommend that.

I have 40 bit WEP configured, you can bet i'm not hiding my ssid.

So how's Doc Brown doing these days? Are Marty and Jennifer still together in this timeline?

Not really interested in working to support the argument either way, was mostly personal curiosity that led me down the path I went. I came away with a better understanding of how wireless networks around me work, and why hidden SSIDs has never been a spec following option in the way most access points implement it.

Contributing to an argument on Twitter where someone's main goal is to prove themselves right and someone else wrong is not really of interest to me. It's a part of myself I'm actively working to improve, as I recognize I've had this behavior in the past and carried it to some unnecessary ends. I'm doing a lot more listening and research these days on a variety of topics, and it's been a great way to grow personally. Being exposed to just a small portion of a recent hate groups tactics on Twitter has me more sensitive to these behaviors as well, and the harm it can cause.

Excellent point.

Understandable, Tom. I'll just point out that my "Twitter argument" is a little overblown. I'm mostly talking this out to see if my own thinking on the subject is correct. If he had come back with a decent argument for the practice, I would have found the exchange intriguing and I might have learned something from it. In my opinion, Twitter isn't going to be a place of reasonable debate due to the structure of such short messages.

It doesn't surprise me at all that I ended up getting the most out of this exchange from Tony'd excellent posts thinking over the topic. Thanks, Tony.

That puts me in mind of a lesson I learned about 30 years ago. A group of us were partners in a commercial radio station, and one of the other partners had an acquaintance visiting the station.

Dann (the other partner and chief engineer at the station) was and possibly still is the smartest person I've ever met. (No, make that second-smartest, I met Patrick Arnold at one of the empeg meets!) He used to make the company that provided our business software crazy. He got hold of a strictly unavailable uncompiler for the software, which was written in a proprietary language used only with Datapoint mini-computers, and he used it to fix software bugs and then send the fixes to the software company. Anyway... this acquaintance of Dann's came by, and I got to sit in while they talked about computers, both hardware and programming.

Now, anybody who has spent any time reading my posts on this bbs knows that I am NOT a computer guru. But what I know now dwarfs what I knew back then. And back then, even I could tell that this acquaintance was sounding off, pretending to know things he obviously didn't, and telling Dann things that I knew were flat wrong. I couldn't wait for him to leave, so I could ask Dann why he didn't straighten the guy out.

Dann looked at me, and said words to the effect that "Why? All it would do is embarrass him, it wouldn't do anybody the least bit of good. I knew he was wrong, but there was no need to prove it at his expense."

I have thought about that discussion many times over the past three decades.

Lesson learned.

tanstaafl.

Thanks, Dignan.

And Doug: Great anecdote.