Muni Wi-Fi security – Part III
So far in this series, I've posted a blog that talked about municipal Wi-Fi security in general and a second blog that talked specifically about Wi-Fi network identification. In this post, I want to cover muni Wi-Fi network authentication. There are essentially two parts involved with Wi-Fi authentication. The first part is how you authenticate to the network and the second is how the network authenticates to you.
Most people are familiar with the first part. Many Wi-Fi networks will dump your browser to a login page where they ask for a username and password, or even a credit card number to use to bill you. Some of the more secure networks will ask you to provide authentication information more directly. I have seen muni Wi-Fi discussions that cover the entire range of these methods and most seem to include the expectation that users will register (on a portal site, like Google, for example) to get an account that they can then use when they want to connect to the Wi-Fi network, which I believe seems reasonable. Some people will no doubt have privacy concerns, because once you authenticate it does become possible to track what you do. But, as far as authentication goes, it's OK. Assuming the muni Wi-Fi operator uses a good security model that doesn't expose your username and password out in the open, there's little direct risk. As long as the user has a simple way to provision an account and only needs to remember a username and password (they'll probably click the "remember my password" box anyway), it should scale properly. Of course, we should still be concerned about fake access points, which brings us to the second part of authentication.
The second part is about how the user can authenticate the access point, which is actually the same problem I talked about in my previous post. In a few municipal cases I've studied, the SSID seems to be the extent of the access point authentication. My previous blog post covered why this is bad, but it is possible to do more. Once we get to the authentication phase, there are technologies that can be used to allow the user to authenticate the access point. First, any login pages that users are directed to should be running over SSL. In this case, the user can verify the SSL certificate to see if it looks legitimate. Now, in my experience, even very technically minded folks tend to ignore the certificate dialogs, so I'm skeptical that this will work very well. Perhaps if there was some software to make these certificates and their content more apparent to the user, in order to distinguish it from the "standard" HTTP certificate information, it might work. There is another possible approach though. There is a technology called EAP (extensible authentication protocol) that can be used to allow for what's called "mutual authentication". This is a mechanism by which the access point actually sends authentication information back to the user during the authentication exchange. From a technical point of view this is a good solution, but I'm not sure how well it's going to work for the rollouts I'm reading about. First of all, not all access points support it and second, it's more complicated to configure and provision. At this point I'm doubtful that many, if any, of the municipal networks will use EAP.
So, what's the bottom line? First, I think when you provision your account for a municipal network, you should use a username and password that has no relation to any other account you have. Even if I already had a Google account, I would create a different one for the muni Wi-Fi network. Second, you should read the certificate dialogs (I know, it's hard to get into that habit) when you connect to any login page. If the login page isn’t running over SSL, don't type in your information. Finally, be very careful about ever entering credit card numbers into login pages. If you can follow these guidelines, you should be pretty safe in terms of authentication.