We’ve all seen it: you walk into a new job, or you’re visiting an office to makes a sales call and see that the shared wireless password is written on every whiteboard.
And even if it’s not written down everywhere, it is probably easy to guess -- try the company’s name with 123 at the end, or the “E”s substituted with “3”s.
Even for those companies with hard-to-guess wireless passwords, the chances that the password was rotated the last time someone left the company is slim. After all, it’s a major productivity disruptor.
This is obviously not good password hygiene; a shared (possibly easy to guess) password that’s rarely rotated is hardly secure.
But does it really matter?
The answer, like just about everything, is “it depends.” There are scenarios where a compromised wireless network is a real threat to the production system, and there are scenarios where (through careful design) the office network needs no password at all.
What’s wrong with a shared wireless password?
There are several major risks with a shared wireless password. Having a shared password increases the likelihood that an attacker can discover it easily, and access your corporate LAN.
While fewer and fewer companies maintain confidential resources on their corporate LAN, your office stills represents a concentration of employees; employees who may have relaxed the fire-sharing or firewalling services on their laptops. Some companies keep local network attached storage (NAS) for backups. And, the attacker will still be able to print “pwn3d” on your office printer until it runs out of paper.
More likely is the attacker can take advantage of an increased level of access granted by sending traffic through your office’s public IP address. Many companies whitelist access to production servers and resources based on the office’s IP address. Oftentimes 2-factor authentication is exempted for traffic from office IP addresses. In these cases, an attacker has a path to attack your sensitive data from your parking lot. And you probably won’t notice.
Whitelisted SSH access from your office to your servers is relatively a low risk. But one of the worst holes is an “admin” web interface to your production service that’s whitelisted to the office. Admin web interfaces are usually very low on the priority list for security patches, since they are “just for internal use”. But now an admin interface running code with known vulnerabilities is an easy target to compromise your entire production database.
Another risk is an ex-employee with an axe to grind. Companies are especially vulnerable here, since this employee has specific knowledge about your company and your architecture. He or she can still get on your network without even entering the building and use this knowledge to attack a known weak spot.
When is a shared password or no password ok?
A wireless network with no password can be useful for guest networks. Guest networks should not use the same public IP address that your employee networks do. These networks should probably have strict bandwidth limits on them. The data will not be encrypted; but since so much traffic is over SSL this isn’t as big of a concern as it used to be.
For offices, a shared password is okay as long as you rotate the password whenever an employee leaves. As a precaution, it’s recommended that you have zero local devices and don’t whitelist the IP anywhere. Anyone accessing production resources should need to use their employee credentials (don’t forget 2-factor!) and/or use a VPN (don’t forget 2-factor!) to access them.
How do I move away from a shared wireless password?
The next progression in wireless security is moving to a log-in system that asks for a username and password.
Every major operating system has support for this, built-in. This means when your computer tries to sign into a network using WPA2-Enterprise, it will ask not for the network’s shared password (which you are used to seeing by now) but instead will pop-up a dialog box asking for username and password. This username and password is a unique combination for each employee.
On the back-end, your access point communicates that name and password to a RADIUS server, which will return a “yes” answer if the name and password are valid, and “no” otherwise.
This requires a RADIUS server. If you don’t have one, there are cloud-provided RADIUS offerings (like [Foxpass](https://www.foxpass.com/)) that can validate usernames and passwords against internal databases or external sources (like Google Apps accounts).
Foxpass has a free 30 day trial and super easy set-up process, so there’s no reason you can’t have this protection today. We’re also free for user counts under 10 people!