Microsoft Windows 10 contains a new behavior called “Wi-Fi Sense“. If you connect to an 802.11 network encrypted using a pre-shared key, Wi-Fi Sense will offer to distribute that key to your Outlook contacts, Skype contacts and Facebook friends. While it is (nominally) opt-in for newly-added networks, this “sharing” is the default behavior for existing networks when migrating from earlier Windows versions to Windows 10.
As an administrator of an 802.11 network you likely would prefer that this “sharing” not happen with the credentials for your network. After the break, I’ll discuss why allowing “Wi-Fi Sense” is such a bad idea, and how you as a network administrator can mitigate the risks it presents.
Why is this so bad?
There are a number of (somewhat overlapping) problems here. I apologize if some of this seems self-evident, but it apparently wasn’t obvious to everyone.
- Wi-Fi Sense asks individual network users to make a security decision those users have no authority to make. If I invite you to my house, open the door and let you inside, that does not mean you can — without consulting me — call Alice and Bob, tell them to come over, and open the door for them. It’s my house; I get to decide who to let in. Likewise, if I let you connect to a wireless network I operate, that does not give you an unlimited, transferrable license to grant others access to that network.
- Wi-Fi Sense asks individual network users to make a security decision those users have no ability to make. If I let someone connect to my wireless network, that does not necessarily mean that person has the skill, training, information and/or motivation to make good decisions regarding distribution of my network credentials. Wi-Fi sense has a complicated trust model. There is no way an average user is going to be able to know all the security consequences of enabling Wi-Fi Sense, nor will that user be able to think through all the second- and higher-order implications of that decision. For that matter, it is unlikely an average user will be able to remember off the top of their head who all of their Outlook contacts, Skype contacts and Facebook friends are. For some users, the union of those sets could easily number in the thousands or tens of thousands.
- Wi-Fi Sense asks individual network users to make a security decision that nobody outside of Microsoft has sufficient information to make. Even if we assume that the information Microsoft has published about Wi-Fi Sense is complete and accurate, we still do not know enough to understand the implications of “sharing” network credentials. Microsoft says that the passphrase is sent “encrypted” and is never seen in plaintext by the recipient. However, passphrase-equivalent information must be present on the recipient’s computer, else they would not be able to access the network in question. We do not know what cipher is used, whether it is implemented correctly, how the keys are managed nor what steps if any are taken to prevent the recipient from retrieving the plaintext passphrase or equivalent. How is Microsoft’s master repository of network credentials secured against future government over-reach or other abuses?
- Wi-Fi Sense retroactively adds risk and complexity. Because Wi-Fi Sense is turned on by default for all network profiles present at the time of an upgrade (from Windows 7, 8, or 8.1 to Windows 10), it means a decision to allow access that was justifiable at the time it was made is now a bad decision. When I let a guest use my wireless network, it (up until now) was on the basis of the assumption that I was granting credentials to a single person and/or a single device. Wi-Fi Sense breaks those assumptions, and breaks them even in cases where the person in question is just clueless rather than malicious.
- Wi-Fi Sense has a broken trust model based on false equivalences. My Facebook “friends”, people whom I count as friends in the real sense, and people with whom I want to share secrets given to me in confidence by third parties are different sets. If I were to use Outlook, it is likely my Outlook contacts would include many people I do not know socially (or at all), and many people to whom I do not want to hand a blank check drawn on someone else’s network resources. If I have a Skype conversation with someone, that means I want to speak to them for a few specific minutes, not that I want them to have the same access to data that I do for an indeterminate period of time.
- Wi-Fi Sense is a complicated and intrusive solution to a non-problem. If I want to make an 802.11 network open, there is already a very easy way to do that. If I want to make it easy for bona-fide guests to use my 802.11 network, there are a number of good solutions, from captive portals to QR codes to NFC tags to completely non-technological things like telling someone the password, typing it for them, or putting it on a sticky note on the fridge. All of these things are easier to use, easier to manage and easier to analyze for risk than Wi-Fi Sense.
- Wi-Fi Sense, by design, is easy to enable inadvertently. Having it on by default for network profiles that exist at the time of an upgrade is one obvious case where Wi-Fi Sense ends up enabled without the user making a conscious, deliberate decision to turn it on. However, there’s a much more insidious one: the check-box when connecting to a new network for the first time. This is nominally opt-in. However, the Windows UI is first and foremost a Skinner box dedicated to training users to immediately respond to any prompt or dialog box with ‘Yes’ or ‘Agree’ or ‘OK’ without pausing to read or think. If I try to format my hard disk, I at least get a prompt that says it will destroy data and asking if I’m sure. Why does Wi-Fi Sense have nothing of the sort when the consequences of turning it on are potentially far more severe and widespread?
- Wi-Fi Sense increases attack surface tremendously. The use case for Wi-Fi Sense is that I can take a mobile device to a location where the only network access is via an 802.11 network run by a friend of a friend, and connect to that network automatically. In order for that to happen, the credentials for that network have to already be on that device (since there is no network connectivity at the moment we know which credentials we need). Thus, Wi-Fi Sense must necessarily push those credentials, in advance, to all the users on the “share” list. If even one of those machines is compromised, then that network is also compromised.
- Wi-Fi Sense creates an irresistible high-value target for attacks. Even if we assume that Microsoft is completely trustworthy, their central database of everyone’s network credentials will attract highly-motivated, highly-skilled, well-financed attackers, both state-sponsored and otherwise. How long will it be before Microsoft gets a “national security letter” because some three-letter agency thinks that’s less work than following the law?
- Wi-Fi Sense exposes its users to liability. (I am not a lawyer. I am not your lawyer. The following is speculation by a lay person, not legal advice.) In most places in the world, unauthorized access to a computer system or network is a crime. Say Bob has a network. He authorizes Alice to use it. Alice gives me the credentials through Wi-Fi sense. I use Bob’s network (perhaps by just walking down the street carrying my laptop near Bob’s house, without ever knowing Bob’s network existed, nor that Alice had shared the credentials with me). Bob never gave me authorization to use his network; I have just committed a crime (and Alice may have done, as well). In the US, I’ve violated at least
In summary, from the perspective of a network administrator, Wi-Fi Sense is a disaster because it subverts and undermines your policy decisions about who gets to use your network and when. It creates new risks where none existed, and does so in the name of (at best) a questionable convenience.
Am I at Risk?
If you do not have an 802.11 network, or if you have such a network and it is by intention open to the public, then Wi-Fi Sense cannot add additional risk.
If you have not in the past given anyone running Windows 7, 8, 8.1, 10 or Phone your network credentials, and you know you will not do so in the future, then Wi-Fi Sense is not a direct risk to you.
If you secure your network using 802.1x, then Wi-Fi Sense will not (according to Microsoft) share those credentials. If you accept that claim as true, then you can believe that Wi-Fi Sense is not a threat to your network.
According to the Windows Phone Features and Availability chart, “Wi-Fi Sense is not available in the following countries/regions: Bangladesh, Brunei Darussalam, Indonesia, Singapore, Taiwan, and Thailand.” So if you’re in one of those places, and you trust Microsoft’s word, and you’re sure all your users and guests have their locale set correctly every time they connect, then you probably don’t have to worry. You know, probably.
If your SSID contains the substring _optout, that will supposedly “opt you out of Wi-Fi Sense”. However, the information from Microsoft is astoundingly vague about what that means. Does Wi-Fi Sense ignore such networks completely? Not send the credentials to Microsoft? Not store them in Microsoft’s central database? Not distribute them to client devices? Or do the credentials still get spread far and wide, and the client devices just don’t connect if they see _optout in the SSID? (The “How do I opt my network out… ?” page contains the chilling text: “It can take several days for your network to be added to the opted-out list for Wi-Fi Sense. If you want to stop your network from being shared sooner than that, you can change your Wi-Fi network password.” That suggests a scenario where the database associates password-equivalent information with your AP MAC address or similar, and obeying _optout is discretionary at the level of the client devices.)
If none of the above convince you your network is safe, I urge you to consider taking steps to mitigate the risk of unauthorized access posed by Wi-Fi Sense.
What Can I Do About It?
The good news is that there are things you can do to help protect yourself. Even better, most of them are things you should be doing anyway (and things that would make sense even in a world where Wi-Fi Sense did not exist).
Change Your Pass-Phrase Now
Have you given your current network pass-phrase to anyone who runs Windows 10? Anyone who might at some point upgrade to Windows 10? If you aren’t 100% sure the answer is “no”, then consider your network compromised. Go change the pass-phrase or key, right now. The credentials for your network are (potentially) out there in the wild. There is no way to get them back. The only recourse you have is to change the locks: invalidate the compromised credentials.
Pros:
- Anyone who can set up an 802.11 network in the first place can do this.
- Can be accomplished in a few minutes on a typical home or small business network.
- Requires no new hardware or software to be installed.
- Provides security even if you assume bad faith on the part of Microsoft.
Cons:
- Not zero-effort, especially on a network with lots of APs and client devices.
- Potentially requires touching every client device unless you have an MDM system.
- As soon as you give the new credentials to a Windows 7, 8, 8.1 or 10 user, you’re back to square one.
I would strongly recommend changing your pass-phrase or key, even if you plan to use other mitigation strategies described below. It will buy you some time to think about what to do next.
Create a Separate SSID for Guests
Businesses probably have this already as a matter of course. It makes sense for home networks, too. In and of itself, this step adds no security. However, it is a prerequisite for some of the later mitigation strategies (like “segregate guest networks” and “rotate guest network passwords”) discussed later. (Exception: If you use 802.1x, you can have everyone on the same SSID but still use separate credentials and implement distinct policies for guests.)
I’m using “guest” very loosely here, as a shorthand for “devices that may leave and connect to foreign networks and/or may be operated by less-trusted or less-technical users” and also for “devices over which the local network administrator does not have complete control”.
Pros:
- Provides a framework for implementing different policies for guests vs. local users.
- Most APs these days, even cheap ones, support multiple SSIDs through a simple config change.
- Does not require client device users to do anything difficult or unfamiliar.
Cons:
- Not every AP supports multiple SSIDs; may require new hardware be installed.
- Some APs may require custom firmware such as OpenWRT or Tomato to use multiple SSIDs.
- Does not provide any additional security on its own.
Rotate Guest Network Passwords
Even if your guests sometimes leak the network credentials you give them, you can mitigate the risk by creating a limited time window during which those credentials are valid. Schedule depends on the specifics of your network, but some channel markers are “change the password often” and “change the password as soon as possible after guests no longer need access”.
Using strong passwords, as always is a good idea. However, mobile devices may present challenges when entering long or complex passwords. Consider alternate means of providing passwords, such as QR codes or NFC tags. Devices like phones (where it is the most difficult to type a long string full of punctuation) are often the very devices which can scan a barcode or read a tag.
The easier you make it on yourself to change passwords, the more likely it is that it’ll get done. Automation is good. Be creative. (Example: Write a Perl script to change the password every other day. Have a web page you can visit — from a device already on the internal network — to see the current password. Have a button you can press to print the current password on an address label printer. Show the current password on an e-ink display on the fridge door.)
Pros:
- Manually changing passwords requires no special skill, software or hardware.
- Still works even if Microsoft isn’t trustworthy.
Cons:
- Hassle for you, the network administrator.
- Hassle for guests who visit more than once.
- Automation requires technical skill, substantial effort and possibly new hardware.
- Still leaves a time window during which your network is vulnerable.
This may be one of the only remedies available to folks running typical home networks who do not have strong networking skills or an IT budget. Even on networks which have 802.1x and RADIUS and multiple VLANs and good firewall rules and a state-of-the-art IDPS, rotating guest credentials is an important part of defense in depth.
Ask Guests to Avoid Sharing Your Network
If Microsoft are to be believed, the decision about whether to share a particular network is made at the time of the first connection. (It is unclear if it is possible for the user to go back later and share a previously-unshared network without re-entering the password. We should assume it is until proven otherwise.) Solving the problem may be as simple as asking your guests to please not check that box.
Pros:
- Easy, non-technical solution.
- Effective assuming guest and Microsoft are both trustworthy.
Cons:
- Requires that you believe Microsoft’s assertions about how Wi-Fi Sense currently works.
- Assumes that Microsoft won’t push an update that changes this aspect of how Wi-Fi Sense works.
- Risk of user enabling Wi-Fi Sense inadvertently.
This doesn’t require you trust your guests beyond the trust required to give them network access in the first place. After all, in a world without Wi-Fi Sense, they could always just post the password to Twitter or something.
Segregate Guest Network Traffic
Once you can distinguish which network clients are guests (for example, because they connect to a different SSID), you can then implement different policies for the network traffic going to and from those clients.
One obvious policy choice would be to limit guest access to local network devices and services. In many instances, guest devices need access only to the Internet, and need not be able to pass packets to or receive packets from devices on the local network. In cases where guest devices do need access to some local resources, it is likely practical to limit the hosts and/or services allowed.
If the guest traffic can be placed on a dedicated VLAN, that can simplify implementing such policy decisions. This can usually be accomplished either by having a separate SSID for guests, or by using 802.1x, or both.
Pros:
- Allows flexibility in setting policy for guest network users, without affecting local users.
- Provides considerable security benefits in general, even in scenarios where Wi-Fi Sense is not in use.
- Does not require anything special on the client side in terms of hardware, software or user skill.
- Many inexpensive access points can run VLAN-aware firmware.
- Adds value even if Microsoft is lying about what Wi-Fi Sense does (or changes their mind in the future).
Cons:
- Requires advanced networking knowledge and considerable work on the part of local network administrator.
- Other network components (such as gateways, switches and local network hosts) may need to be VLAN-aware, and may require special configuration.
- Access points may need special firmware loaded (or even hardware replacement) to enable multiple VLANs.
- Adds complexity to the network topology.
If you’re running a business network and have guest network access at all, then you’re either doing this already or you need to. It’s just part of being professional.
On a home network, if you have the equipment and the skills, segregating your network into multiple VLANs gives you a lot of flexibility and security. If its within your reach, consider doing so.
Some “all-in-one” SOHO network devices (which act as both gateway and wireless access point) may let you implement a simple version of this approach, where you define a second SSID and give it access to only the Internet, not the LAN (nor other wireless clients on any SSID).
Implement 802.1x
Allegedly, Wi-Fi Sense will not “share” the credentials for a network that uses 802.1x for authentication. This assertion is at least marginally credible given that doing so would hack off the business users about whom Microsoft apparently cares.
Pros:
- According the Microsoft, sidesteps Wi-Fi Sense and the problems associated therewith.
- Improves security in general.
- Improves flexibility.
- Conformant with generally recognized “best practices” for wireless networking.
- In most cases, even cheap SOHO access points support 802.1x (“WPA2 Enterprise”).
Cons:
- Adds complexity; may be beyond the technical reach of the typical home user.
- Typically requires the use of a separate authentication server (RADIUS or similar).
- Easy for even technically adept users to misconfigure in in insecure ways (though certainly not “Wi-Fi Sense” levels of insecure!).
- Nothing is stopping Microsoft from sharing username/password combinations and/or client certificates, either now or in the future.
If it is within your reach, 802.1x should probably be regarded as “necessary, but not sufficient”. A scenario where Microsoft “shares” 802.1x credentials between users seems unlikely. However, a scenario where Microsoft “phones home” with those credentials and they are later stolen, seized or voluntarily disclosed to criminals acting under color of law is plausible. If you can do 802.1x, you can do password rotation and two-factor auth.
Use Two-Factor Authentication
Single-factor authentication regulates network access based on something the user knows (such as a password or PIN). Two-factor authentication improves upon this by requiring both something the user knows and something the user has (such as a physical token). (There is also three-factor auth, which adds a check for something the user is — in other words, biometrics like fingerprints or retina scans. If you’re doing that, you’ve gone well beyond the scope of this blog post.)
Implemented correctly, two-factor authentication adds a lot of security. It would certainly raise the bar for automated intrusion via Wi-Fi Sense.
However, two-factor auth has limited value where the authentication token and the device for which network access is being controlled are the same thing. If you’re deciding whether or not to let a laptop computer join your network, don’t count on a software token running on that same laptop as a second factor.
The most straightforward route to two-factor authentication on a wireless network may be to implement 802.1x with a RADIUS server providing the authentication. There are lots of options for doing two-factor auth with RADIUS.
Practice Defense in Depth
Preventing unauthorized access to your network at the MAC layer isn’t (or at least shouldn’t be) your only network security. Instead, it should be one of a number of strategies used in parallel to increase the expected cost to the attacker and decrease the expected harm to you should an attack occur.
Turn off un-needed network services. Uninstall software that isn’t used. When possible, avoid extending trust based on mere presence of a client within the same broadcast domain or IP block. Use strong, peer-reviewed encryption at the session and/or application layer (SSH, TLS, IPSec) even when both parties are on the local network.
If a host doesn’t need to be on your network, don’t connect it. If it only needs to be on your network for 15 minutes once a year to pull a firmware update, then only connect it long enough for it to do that. If a host only needs to see the Internet and not local servers, put it on a VLAN that enforces that restriction. Likewise, if a host only needs to see local servers and should not be passing traffic to or from the Internet, enforce that.
No single layer of security will ever be bulletproof. Have enough layers so that the inevitable holes don’t line up in a way that adds up to trouble for you.
What Shouldn’t I Bother With?
You only have a limited amount of time and money to spend on network security. That’s true regardless of whether you’re Sony, the Pentagon, or my dad; the differences are only in scale. So, to achieve good network security, you need to spend your limited resources where they’re likely to do the most good. This sections talks about some things that might seem like good ideas, but which don’t really help. Skip these, and spend the time doing something useful (or fun) instead.
Don’t Bother Putting _optout in Your SSID
It doesn’t seem like it would do much harm, but it certainly isn’t sufficient alone:
- You have to take Microsoft’s word about what it does.
- All Microsoft really tells you is that it will “opt you out of Wi-Fi Sense”. (Maybe the credentials are still sent to MS. Maybe they still get stored in a central database. Maybe they still get transmitted to all your Facebook friends, and its just the local network stack that decides not to connect.)
- Microsoft could (and their history suggests they would) change their minds about this tomorrow.
- Going along with “opt out” scheme is capitulation. It’s feeding the trolls. It’s paying ransom to kidnappers. Having unauthorized users intrude on my network is not something I should have to “opt out” of; the sheer hubris required to suggest otherwise is staggering.
- Putting _optout in your SSID broadcasts to the world “Here is someone who follow infosec news, and who has something to protect.” Doing that, in and of itself, leaks actionable information to potential attackers and thereby creates risk.
If your network credentials were already leaked through Wi-Fi Sense, then adding _optout to your SSID certainly will not help. Those credentials are out there in the wild; you can only revoke them, not “unpublish” them.
Yes, Microsoft says they’re encrypted and the users they’re shared with never see cleartext. But password-equivalent information has to exist on those users’ computers for them to connect to the network. If it’s on a computer I physically control, that’s game over — I can see it. Cryptography is a way for Alice to send a message to Bob without Charlie being able to read it. It is fundamentally impossible to create a working cryptosystem in the case where Bob and Charlie are the same person. There is no way to send something to my computer in such a way that my network stack can see it and I cannot. The sheer tonnage of failed DRM schemes over the years should convince you of this.
Also consider Microsoft’s own words: “It can take several days for your network to be added to the opted-out list for Wi-Fi Sense.” However many days “several” is, it’s way too long to leave your metaphorical front door unlocked.
Don’t Bother using MAC Address Filtering
It is trivially easy for attackers to guess client MAC addresses. It is even easier than that for attackers to capture client MAC addresses over the air, completely passively, without knowing any network credentials.
Attackers can change their MAC address to anything they want with the press of a key.
MAC address filtering is a huge maintenance hassle on the network infrastructure side and raises the security bar very little.
The only situation I’ve seen where I consider MAC address filtering justified is on a network with legacy 802.11b clients that did not support anything beyond WEP. Even then, it was used in combination with physical access control, and on an isolated VLAN behind a very restrictive firewall.
Don’t Bother Turning Off SSID Broadcast
On the surface, disabling broadcast of you SSID seems like a security win: don’t advertise your network; only allow access to clients who already know it’s there.
It isn’t that simple.
One problem is that if any attacker ever hears any of your network traffic, they have your SSID. This is true even if you have effective encryption and authentication, even if you use 802.1x, and even if you’re running IPSec or some other VPN on top of all that. It’s sent, in the clear, in every 802.11 frame and there’s no turning that off.
Another problem is that clients that want to connect to your “hidden” network automatically have to probe for it. In other words, you stop sending out your SSID in the immediate vicinity of your network, but clients now start sending out your SSID everywhere they go. (Next time you’re at an airport or big hotel, fire up kismet and see how many “probe” networks show up.)
Conclusions
Wi-Fi Sense is a bad idea. It potentially causes serious problems. The only benefit it offers to the end-user in return is the chance to avoid a trivial inconvenience in a very limited set of circumstances.
There are ways to mitigate the problems posed by Wi-Fi Sense.
Some of these ways are a procedural and/or social, and require no special technical skill or equipment.
Most of the things that help prevent problems caused by Wi-Fi Sense help prevent other problems too, and are good ideas in general.
Microsoft’s suggestion to put _optout in your SSID is not especially helpful.
Disabling SSID broadcast and using MAC address filtering are both common practices, but are not best practices. In fact, both are counterproductive.
2015 August 16 DGH — Added 802.1x section I had planned but completely forgotten to write on the first go-around.