Home → Opinion → Articles → Enterprise Wi-Fi: We Need Devices That Are Secure... → Full Text

Enterprise Wi-Fi: We Need Devices That Are Secure by Default

By Alberto Bartoli, Eric Medvet, Andrea De Lorenzo, Fabiano Tarlao

Communications of the ACM, Vol. 62 No. 5, Pages 33-35

[article image]

Save PDF

Would you trust security technology that makes it possible (that is, quite likely) to steal the single sign-on enterprise credentials of any specific person in your enterprise by merely walking within 30 meters from that person? The attacker does not need to do any visible activity that might raise suspicions: a 50-euros device in a bag and a few seconds of physical proximity is all that is needed. Active cooperation of the target is not required and Internet connectivity is not required either. Thus, the attack may occur anywhere and the target would not notice anything. The attacker could steal the single sign-on credentials of a large fraction of people of your enterprise that happen to pass within 30 meters from the attacker. Perhaps at the office lunchroom, near a mass-transportation hub, or anywhere outside of the enterprise.

Of course, you would not trust such a security technology. Interestingly, though, a technology of this kind is nearly ubiquitous and implicitly trusted by a lot of people and enterprises: it is WPA2 Enterprisethe suite of protocols for secure communication in enterprise wireless networks. It is necessary to emphasize the relevance of this important and pervasive yet largely underestimated risk. We need to raise the awareness on a fundamental security technology that is very often deployed by violating its requirements, which creates important risks to users.

Back to Top

Stealing Enterprise Credentials with Evil Twins

The attack scenario described in this Viewpoint may succeed whenever people connect to enterprise wireless networks with devices that are not configured correctly. We recently showed (see Bartoli et al.2) that by just wandering around for a few hours in regions not covered by a wireless network we could have collected 200 enterprise credentialsapproximately 25% of them in clear text and the remaining ones in hashed MS-CHAPv2 formwhich can generally be decrypted easily.9 We also showed that by remaining for a few seconds at less than 35 meters from a specific (voluntary) target whose Wi-Fi device is not configured correctly, there is a very good chance the attacker may steal his/her enterprise credentials; even when he/she is sitting in a car with closed windows.

The reason why these attacks work is quite simple. A Wi-Fi device (a supplicant in WPA2 Enterprise) may connect to an enterprise network only after executing an authentication protocol with the authentication server for that network. For the purpose of this Viewpoint, this protocol may be summarized as follows:

  1. The supplicant verifies the identity of the authorization server for the network it is attempting to connect to;
  2. The supplicant sends user credentials material to the authorization server; and
  3. The authorization server demonstrates knowledge of the user credentials to the supplicant.

Execution of the first step relies on certain configuration information that must be stored on the supplicant before connecting. Such information includes the association between the name of the network and the name of the authorization server (for example, in our university these are eduroam and raggio.units.it, respectively); it also includes the association between the name of the authorization server and a certified public key for that server.

Satisfying this configuration requirement is extremely important, because supplicants that are not configured correctly will execute the first step with any fraudulent Wi-Fi access point broadcasting the name of an enterprise network (evil twin).3,4,7,9 The authentication protocol will fail because the evil twin will not be able to prove knowledge of the user credentials. However, the supplicant will disconnect when it is too late, that is, after having already sent credential material to the evil twin. The entire procedure takes just a few seconds and, most importantly, it does not require any engagement from the user, in particular when the user carries a smartphone with the Wi-Fi interface active.

Back to Top

Enterprise Wi-Fi Today

Enterprise credential stealing through evil twins is not based on any vulnerability of WPA2 Enterprise: it is an obvious consequence of using this technology without satisfying one of its fundamental deployment requirements, that is, correct supplicant configuration.8 The problem is, supplicants that connect to enterprise networks without being configured correctly are pervasive. All the analyses we are aware of corroborate this claim unequivocally and even network configuration guides prepared by organizations suggest insecure configuration practices very often.1 Attacks based on an evil twin have thus a high probability of success.

What makes this risk important and pervasive is that WPA2 Enterprise was specified in 2004 but the world today is very different:

  • Virtually all enterprises have migrated to single sign-on architectures. Enterprise network credentials now usually unlock access to all enterprise services, including in particular all the services with a Web interface. Network credentials are thus much more attractive and valuable to attackers than they used to be.
  • Most people are now permanently carrying a Wi-Fi-enabled smartphone that often contains the user's enterprise credentials and connects to Wi-Fi networks automatically. An evil twin may now be assembled with a few tens of euros and can be placed in a bag.2 Attacks aimed at stealing network credentials may thus occur potentially anywhere and are virtually impossible to detect: they are executed automatically, in less than a second of proximity to an evil twin and without any need of involving the device owner in a working session.

One of the reasons for the prevalence of incorrectly configured supplicants is because defining an insecure configuration is much simpler and quicker than defining a secure one. A secure configuration requires the presence of certain configuration data on the supplicant, which must be preliminarily obtained through a connection link different from the enterprise network. Insecure configurations are much more straightforward to define as they do not require any prior connection and download: select the name of the enterprise network, insert enterprise credentials, and then play with the network configuration until connecting, the most typical (insecure) options being "skip certificate validation" or "accept any certificate." Users are not to blame for this behavior, as they cannot appreciate the resulting risks. Most importantly, they have no incentive in selecting a more cumbersome path toward their objective: connecting their device to the network.5

One could require enterprises to deploy forms of "entrapments" for detecting supplicants that are not configured correctly and then notifying the corresponding users to contact the IT staff. On the other hand, it is a fact that many organizations not only tolerate but also suggest insecure configuration practices,1 hence assuming the occurrence on a large scale of a spontaneous change that increases the technical and operational burden of IT staff seems to be excessively optimistic. Indeed, procedures of this kind may be implemented already but it is fair to say they are actually deployed quite rarely.

Back to Top

Secure by Default

We call on the technical community to disseminate the awareness that we are systematically deploying a widespread security technology by violating its key requirements, thereby creating important risks to users and organizations. WPA2 Enterprise devices will not disappear anytime soon, thus we must all be aware we will have to cope with the pervasive risks of enterprise Wi-Fi for many years to come.

We also need to devise a transition plan that, in our opinion, necessarily requires a novel design for supplicants. The root cause of the problem is that users invariably attempt to connect their supplicants by providing only the name of the enterprise network, that is, without preliminarily obtaining the additional information required for a secure configuration. Consequently, we advocate a design that makes it impossible for those supplicants to connect. We believe this is the only realistic strategy for providing both users and enterprises with adequate incentives for installing the required information on supplicants.

Obviously, supplicant configuration should be sufficiently simple to make the new framework acceptable in practice and the likelihood of ending up in insecure configurations should be minimized. These generic recommendations can be made more useful and concrete based on secure by default design principles:6 configuration should not require specific technical understanding and it should require only the insertion of a few short pieces of textual information (to prevent the need of non-obvious actions from the user such as downloading and installing a program or binary data with a device not yet connected to the network). Although these design principles do not prevent the possibility of insecure configurations, they are sufficiently specific to be actionable.

Although these design principles do not prevent the possibility of insecure configurations, they are sufficiently specific to be actionable.

We have proposed a design based on this framework2 but we believe any secure by default approach needs strong incentives that cannot be purely technical.5 Manufacturers are unlikely to place on the market supplicants whose configuration involves a user experience quite different from the established one. Support from a standards body in the form of certification requirements for supplicants could constitute a strong and probably decisive incentive for adopting a secure by default approach in the context of enterprise Wi-Fi.

There is an important opportunity in this respect, because the Wi-Fi Alliance has announced new security protections will be specified soon as part of the new family of WPA3 protocols.10 It is unclear whether the issue of supplicant configuration in enterprise Wi-Fi will be addressed and how: the limited information that is currently available is not very encouraging, as the focus is on new cryptographic protections but crucial issues of supplicant configuration are not mentioned at all.10 It would be unfortunate if the new standard did not remove security assumptions that have proven to be unrealistic, as the society as a whole would have to cope with the resulting risks without any transition plan on the horizon. We can no longer afford devices that are secure only if configured correctly, but that may be used insecurely anyway and are typically used so.

Back to Top


1. Bartoli, A. et al. (In)Secure Configuration Practices of WPA2 Enterprise Supplicants. In Proceedings of the 13th International Conference on Availability, Reliability and Security; https://dl.acm.org/citation.cfm?id=3230838

2. Bartoli, A., Medvet, E., and Onesti, F. Evil twins and WPA2 Enterprise: A coming security disaster? Comput. Secur. 74 (2018), 111.

3. Brenza, S., Pawlowski, A., and Pöpper, C. A practical investigation of identity theft vulnerabilities in Eduroam. In Proceedings of the 8th ACM Conference on Security and Privacy in Wireless and Mobile Networks. ACM, NY, 2015, 114.

4. Cassola, A. et al. A Practical, Targeted, and Stealthy Attack Against WPA Enterprise Authentication. NDSSNetwork and Distributed Security Symposium. 2013; https://www.ndss-symposium.org/ndss2013/ndss-2013-programme/practical-targeted-and-stealthy-attack-against-wpa-enterprise-authentication/

5. Schneider, F.B. Impediments with policy interventions to foster cybersecurity. Commun. ACM 61, 3 (Mar. 2018), 3638; doi: 10.1145/3180493

6. Secure by Default. National Cyber Security Centre [Internet], (May 2, 2017); https://www.ncsc.gov.uk/articles/secure-default

7. Snodgrass, J. BYO-Disaster and Why Corporate Wireless Security Still Sucks. DEFCON 21; https://www.defcon.org/images/defcon-21/dc-21-presentations/djwishbone-PuNk1nPo0p/DEFCON-21-djwishbone-PuNk1nPo0p-BYO-Disaster-Updated.pdf

8. Souppaya, M. and Scarfone, K. Guidelines for securing wireless local area networks (WLANs). NIST Spec Pub. belt.es; 2012;800: 153; https://www.nist.gov/publications/guidelines-securing-wireless-local-area-networks-wlans-0

9. Weaknesses in MS-CHAPv2 authentication. Microsoft Technet (Aug. 20, 2012); https://blogs.technet.microsoft.com/srd/2012/08/20/weaknesses-in-ms-chapv2-authentication/

10. Wi-Fi Alliance introduces security enhancements. In Wi-Fi Alliance (Jan. 8, 2018); https://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-introduces-security-enhancements

Back to Top


Alberto Bartoli ([email protected]) is an associate professor at the University of Trieste, Italy.

Eric Medvet ([email protected]) is an assistant professor at the University of Trieste, Italy.

Andrea De Lorenzo ([email protected]) is a research fellow at the University of Trieste, Italy.

Fabiano Tarlao ([email protected]) is a research fellow at the University of Trieste, Italy.

Copyright held by authors.
Request permission to (re)publish from the owner/author

The Digital Library is published by the Association for Computing Machinery. Copyright © 2019 ACM, Inc.


No entries found