Public WiFi in Response to KRACK

Public WiFi in Response to KRACK

WiFi security has been in the headlines lately in response to the Key Reinstallation Attack (KRACK). The KRACK vulnerability targets the WPA2 protocol – the protocol modern devices use to communicate with wireless access points (WAPs). With that in mind, organizations should consider having a conversation with their employees about public WiFi in response to KRACK.

KRACK is effectively a man-in-the-middle attack. Attackers broadcast a phony wireless signal that mimics the real network that victims are trying to join. The bad guys then have the ability to install an encryption key on the victim’s devices once connected, which can be used to read information that was previously assumed to be safely encrypted by WPA2.

Protecting Devices from KRACK

Protect Devices from Public WiFi in Response to KRACK

The good news is that the fix for KRACK can be as simple as installing manufacturer updates that most vendors have already released in response to KRACK. In most cases, users will be protected if they update their devices.

The issue is these updates won’t eliminate the KRACK vulnerability, only patch the security hole for updated devices. That means attackers will still have the ability to breach security on wireless access points that have not been updated or that cannot be updated.

That is why it is critical that everyone uses this attack as an opportunity to consider their overall WiFi security posture and come together as a community to protect ourselves from the bad guys.

Public WiFi in Response to KRACK

Public WiFi in Response to KRACK

With that in mind, we must face some hard truths about WiFi security in response to KRACK. One topic that is critical for organizations to consider is the use of public WiFi.

A lot of people enjoy having the ability to work remotely. Not only has it been proven to increase productivity, but people just enjoy the freedom of working where they want. Despite these advantages, there are a number of serious security drawbacks to this approach – especially with the knowledge of vulnerabilities like KRACK existing in the wild.

In an ideal world, everyone would be aware of KRACK and would have already taken the necessary steps to protect themselves. But that’s not the world we live in, and KRACK will likely continue to claim victims.

Public WiFi only exacerbates those risks because users connecting to public WiFi are effectively placing their devices on an attack surface that they cannot define. To provide a counterexample, let us assume that your organization has taken the necessary steps to protect their network and devices from KRACK. IT admins likely know which devices are at risk and have taken steps to protect them.

The same cannot be said with certainty for public WiFi networks. The sad truth is that it is nearly impossible to be sure if your device is protected from KRACK when using public WiFi. Unfortunately, the best way to protect yourself is to not use public WiFi until you have been patched and you can confirm that the public access point has been patched as well. Unfortunately, you may not be able to tell this in advance. It is likely that well known public WiFi systems may be updated just because these organizations are likely better at their IT infrastructure, but, of course, you may not be able to say that with certainty.

To be safe, you may want to use your smartphone to tether to the internet instead. While this may be more expensive in the short run, it is likely much safer. Over time, as organizations continue to update their hardware and software on access points the KRACK vulnerability will be resolved.

Best Practices for WiFi Security in Response to KRACK

Best Practices security practices for Public WiFi in Response to KRACK

Thankfully, there are proven methods for protecting yourself from KRACK. As previously noted, the first step is ensuring that all of your WAPs and devices (e.g. systems, servers, appliances) that have access to WiFi have the latest security patches installed.

The next step is to only use trusted networks, at the very least when transmitting sensitive information. Yet, even trusted networks are vulnerable if they are using the shared SSID and passphrase model.

Attackers didn’t need KRACK to breach this type of security.

That is why the best practices for securing WiFi include implementing RADIUS. RADIUS is a form of WiFi authentication that provides a unique set of credentials for each user attempting to gain access to the network. In doing so, authentication to the network is achieved on an individual basis. Access can also be revoked on an individual basis by an admin at any time.

This isn’t possible with the shared SSID and passphrase approach. The only way to offboard one employee from the WiFi network is to change the credentials for everyone on the network – which can be a huge headache for larger organizations. That is why RADIUS is so effective, because administrators have the ability to restrict access individually, in some cases with the click of a button.

Yet, if RADIUS is so effective, why aren’t RADIUS implementations more common?

It used to be that implementing RADIUS was a major challenge. Administrators would have to purchase the RADIUS server(s) and all of the infrastructure that goes along with it. They would have to stand up the server, and point all of their endpoints to the RADIUS server. Then they would have to maintain it, because if the RADIUS server went down, users wouldn’t be able to login to the network.

These are a few of the reasons why so many organizations prefer the shared SSID and passphrase model, it’s just easier. While that may be true, it is critical that organizations are mindful to the fact that this shortcut comes at the expense of WiFi security.

WiFi Security with Directory-as-a-Service®

Fortunately, some of the best modern cloud IAM solutions have the ability to provide RADIUS-as-a-Service. Directory-as-a-Service is one such solution.

RADIUS-as-a-Service is a core aspect of Directory-as-a-Service. It provides all of the same benefits of a conventional RADIUS implementation, as listed above. The main difference is that organizations no longer have the responsibility of implementing and maintaining RADIUS infrastructure.

JumpCloud takes care of most of the heavy lifting. Admins simply point their wireless access points at the JumpCloud RADIUS server, and we take care of the rest. While unfortunately it won’t protect people using public WiFi in response to KRACK, RADIUS is perhaps the best step organizations can take to secure their WiFi.

Learn more about how JumpCloud and Public WiFi in Response to KRACK

To learn more about the risks of using public WiFi in response to KRACK, or how JumpCloud’s RADIUS-as-a-Service can help secure your WiFi network, drop us a note. You can also sign up for a Directory-as-a-Service account and secure your network with RADIUS-as-a-Service today. Your first ten users are on us so you can see first hand just how powerful Directory-as-a-Service can be for free.

Vince is a documentation and blog writer at JumpCloud. He recently graduated with a degree in professional and technical writing from the University of New Mexico. Other than writing for JumpCloud, Vince enjoys wearing sweaters and sampling local beer in Boulder, CO.

This is a Security Bloggers Network syndicated blog post. Read the original at: JumpCloud 2017-11-10.

Vince Lujan

Vince is a documentation and blog writer at JumpCloud, the world’s first cloud-based directory service. Vince recently graduated with a degree in professional and technical writing from the University of New Mexico, and enjoys researching new innovations in cloud architecture and infrastructure.

vince-lujan has 30 posts and counting.See all posts by vince-lujan