Securing Wireless Networks Internally

WEP, WPA/WPA2, and the associated authentication methods are designed to keep invaders out. However, it has become increasingly easier to crack WEP encrypted networks and cracking WPA/WPA2 networks is difficult, but feasible. These methods help keep external users from being able to access sensitive data, but what about internal, authenticated users?

Internal wireless security is important when utilizing networks of hundreds of users. Say I have a WPA2 AES encrypted network. A normal user will connect to the network and be granted access to the internal wireless network. Unlike wired networks, wireless networks do not have switches to direct traffic to the right ports (users), therefore, every authenticated user can see everybody else's traffic. Now, with a network of hundreds of users, this can pose a problem. Once somebody is authenticated, they are free to sniff traffic, perform man-in-the-middle attacks, etc. It doesn't matter what encryption method (WEP, WPA/WPA2) was used because each authenticated user is using the same key as everyone else to encrypt their data.

For example, many universities are now creating wireless networks around campus which hundreds of students may be connected to simultaneously. What is preventing one student from logging onto the wireless and sniffing all traffic from the gateway until he gets some passwords? Information like that can be used to access someone's email account and once your email account is compromised, you're hosed (hint, "Forgot Password?")

The standard solution to this problem is VPN tunnels. Here's an example, a user joins an open access point provided by the company. When he opens his browser, he is redirected to a page where he needs to download and install the VPN client. After installation, the user will login and the VPN client sets up an encrypted, independent tunnel. Now, he is safe from both external and internal hackers because every bit of his data goes through this tunnel and is encrypted. You could do a man-in-the-middle attack, but all you'll get is encrypted packets.

However, the implementation may not be an option for universities or companies who give 2 cents about user friendliness. Establishing a VPN tunnel requires a client program. That's one more program users need to install on their computers; one more program that users DO NOT want to install. Not only that, the VPN client is yet another product the IT department must support and it also creates an additional level of failure. Some product's installation procedures are less than stellar and can cause more headaches than smiles. You also have to look at how easy it will be to implement over the existing system, support options, delivery of the client, and finally, compatibility. With Windows Vista and it's dreaded UAC, installation of a VPN client has become even more of a hassle that some vendors are trying to overcome for the sake of user friendliness.

A simple solution would be to issue different, unique keys to each user. This encrypts their data with different keys and would act like a VPN tunnel. You could "MacGuyver" it and create an access point with a different key for each user, but that relies on IT "manual labor" and is vastly inefficient. However, if each user got a different key, there would be no client program (a plus for user friendliness) and no additional hardware needed if the software lies on the access point or controller.