New attack on WPA using PMKID | Hacker News Reader

New attack on WPA using PMKID

hashcat.net

228 pointsnewman8r75 comments

Sometimes I wonder if trying to encrypt WiFi is even worth it. "E2EE or GTFO" is pretty compelling.

The counterargument is keeping packet headers (i.e. remote IP addresses) and plaintext DNS queries private, but that's already the use case of a VPN. Even if it's just a "VPN" to your own home router. And then it protects you even against the operator of the access point (or someone impersonating it because, as usual, the passphrase is widely distributed).

It also depends on the bandwidth available. Average users don't overpay for unlimited.

Even if encryption isn't worth it, the access controls it gives you are to most access point owners. By limiting who can connect an owner can reduce bandwidth usage, improve latency, and increase the quality of their connection.

Not to mention that most protocols in current use at minimum leak metadata. There would need to be a standard for an automatic authenticated VPN supported by hotspots and operating systems. Regular users shouldn't need to perform complex setup procedures.

And at that point, while I do like the seperation on concerns provided, why not just fix or replace WPA?

Even for that, it's not the ideal layer. A basic connection should generally be available for everyone even if it's a rate-limited logically-separated segment that only provides internet access. Then if you want special treatment for a specific subset of users they need something on top of that, but only that subset of users -- notably not the ones who come and go all the time -- and authenticating them has no real relation to the WiFi. A VPN to an endpoint on the same LAN works for this. There is also 802.1X, IPSec, etc., which common operating systems already support.

Meanwhile the guest users should have their own external VPN to protect them from you, which they should only have to set up once for all networks.

Free.fr does exactly that. Any subscriber can use a small amount of bandwidth on any free.fr wifi nearby, with a lower traffic priority than the owner.

> A basic connection should generally be available for everyone even if it's a rate-limited logically-separated segment that only provides internet access.

As long as you're legally responsible for the traffic coming out of your network, this is not a good thing to do. Unless people explicitly get the same protection an ISP gets, I'll keep advising them to not to share their connection openly.

> As long as you're legally responsible for the traffic coming out of your network, this is not a good thing to do. Unless people explicitly get the same protection an ISP gets, I'll keep advising them to not to share their connection openly.

That is obviously a jurisdiction-dependent legal question and anyone concerned about it should consult an attorney.

But if you're suggesting that, for example, the CDA or DMCA safe harbors only apply to Comcast and not book stores or auto shops or anyone else that provides public WiFi, I would be interested to see a citation for that.

I didn't mean DMCA only. Rather general dealing with law enforcement in general.

But even with just DMCA to be a safe harbour you need to: have a service policy, show it to the users, have the possibility to prevent access for identified violations, and effectively keep some kind of connection record to be able to identify which users you need to terminate. I doubt anyone fulfills that at home. (I don't think shops and cafes do either)

I feel like this is why the advice is always to consult an attorney. If the law has some easy to fulfill requirement (service policy) then concerned people should have one even if they're only providing access to Uncle Bob and not the general public. It may not be likely that Uncle Bob would cause any trouble (though maybe his computer is infected), but it may not be likely that anyone with physical proximity would cause any trouble. If you're worried about it then why not do the thing that mitigates the risk regardless?

It's even possible that not providing public access may increase certain risks. If you restrict access and someone guesses/cracks the password and does something terrible, that may make it harder to argue that it wasn't you.

I'm also not sure where you're reading the requirement to identify the users. There are many sites (e.g. Slashdot) where users can post anonymously (and via Tor or equivalent). Are you saying they don't qualify?

They have some info here:

https://openwireless.org/myths-legal.html

But notice that half the page is dedicated to extra-legal ISP shenanigans, which brings us back to routing your whole internet connection (guest net included) through a VPN. Which, again, you probably want even if you're the only one on your connection. It's not as if copyright trolls are renowned for their accuracy in targeting only people who are actually infringing something.

> I'm also not sure where you're reading the requirement to identify the users.

Not identify as in get their names. Just identify enough to know when they come back. Knowing which MAC to filter would probably be enough.

http://digital-law-online.info/lpdi1.0/treatise39.html

> First, the service provider is expected to adopt and reasonably implement a policy for the termination in appropriate circumstances of the accounts of subscribers of the provider’s service who are repeat online infringers of copyright.

You'd need to also identify which device was infringing by getting a connection time/destination.

> You'd need to also identify which device was infringing by getting a connection time/destination.

I still don't see where it says you have to do that. Your link doesn't seem to say anything about it.

I question the value of MAC address blocking in general. Anyone can change their MAC address and popular systems are even using MAC address randomization by default now.

And in a physically local context like this, couldn't you just tell the person they're not allowed to use your wireless anymore, or remove them from the property?

The issue is who has to identify the user. If all they gave you was your own IP address with no accurate timestamp or ports, you wouldn't even be able to get the effectively-useless MAC address, even with the connection records most people don't keep. If they gave you the user's legal name (e.g. because the user signed up for the file sharing service with it) then you wouldn't need any connection records.

The MAC is just an example. You need some way to block someone abusing your connection. It's the first point raised in the requirements for safe harbour. For this you need to be able to say "this is the same person/device as before".

> couldn't you just tell the person they're not allowed to use your wireless anymore

The context we started with is wifi open to the public. You've never met your users and you may never see them (directional antenna from a distance), so the legal name is not useful either.

The situation where you know the users is much simpler.

> The MAC is just an example. You need some way to block someone abusing your connection.

You're thinking like a sysadmin. Think like an organization.

Compare the situation where you have a public space where everyone is welcome except Bob, because when Bob was there in the past he caused trouble and was asked never to come back.

You don't have to post guards checking ID because Bob knows he's not invited and the laws against trespassing deter him from showing up.

> The context we started with is wifi open to the public. You've never met your users and you may never see them (directional antenna from a distance), so the legal name is not useful either.

Seeing isn't required for telling. If you have the legal name, why can't you send a certified letter telling them they're not allowed to use your network anymore, then if they continue you call the police?

It's not worth it in my opinion. That's why networking is layered. If security is desired,it should be layeres on top not integrated as part of a layer.

TLS for example is layered on top of Layer4(tcp/udp). It's not part of the tcp standard or something.

Wifi or wired,Segment level security should have it's own layer on top of or under Ethernet. Maybe 802.11ae falls under this?

Even if it's just a "VPN" to your own home router.

Then I guess people would crack the VPN auth protocol.

Primary reason why I have encrypted AP is because I have limited bandwidth per month, as pretty much everyone else with few exceptions. Having open AP would literally lead to me paying hundreds in over-usage fees.

Can anyone provide a brief summary of the state of the art of WPA cracking? How many bits of entropy do I need in my wireless password these days to deal with cloud GPUs?

80-bit of entropy, generated from a 6-word diceware is sufficient for almost every application. The real issue in WPA is the lack of forward secrecy, without it, once the passphrase is known, all previously recorded traffic is revealed.

That is a very minor issue compared to the easy password hash, no encryption for open networks, deauth attack, etc.

nobody is going to spend the atrociously high cost of cloud gpus to crack someones home wifi password in an un-targeted attack. your home wifi threat actor is your neighbors kid playing with aircrack.

in a corporate environment, use wpa2-enterprise, then password entropy doesnt matter quite as much.

I thought enterprise was even more fucked thanks to the horror that is MSCHAPv2 and that no one bothers to setup the PKI stuff to authenticate the APs.

In WPA-EAP the AP is not active part of the authentication flow (it only forwards the frames) and as such does not directly authenticate itself to the client (it happens indirectly by the fact that it can forward the frames).

The configuration space of WPA-EAP is huge and most combinations are horribly insecure, but as long as you stick with one of the "tunnel everything through TLS" EAPs (EAP-TTLS or PEAP) the result is safe against passive attackers even when you don't verify server certificates (obviously you should verify the certificates, because the active attack is trivial and does not have to interact with your network).

How would one setup the certificates in a right way? I presume that needs MDM anyways to conveniently distribute the certificates?

You can do it without MDM, just distribute via an https webpage. Most universities do this, because it is 90% byod or guest access (you can only be enrolled in one MDM).

So guests coming to your home would need to first download certificates in order to be able to trust your network. But they would then need to trust that certificate not to be used to MITM their own EAP servers... This doesn’t sound very user friendly. Am I missing something?

Certificates, not CAs.

Right. Of course.

This is the model for "Eduroam" (Academics and students at various educational institutions, particularly in Europe but these days around the world have a single network). Each device is configured with certs for their home institution, their username lets any member figure out where that home institution is, and so their password or other authentication flows only to an IdP for that institution, which under the Eduroam agreement is trusted to authenticate them at all other member institutions.

So you set up "eduroam" once on your phone, and then it works the same in a lecture theatre at Stanford, or in Nantes (France). So that's nice, and as dfox observes the AP isn't much involved, so the inevitable frailty of individual WiFi setups in less sophisticated institutions isn't a huge flaw in Eduroam or a grave risk for your home institution.

> your home wifi threat actor is your neighbors kid playing with aircrack.

When working for an ISP it came up quite a few times that customers had extensive questions about security because they were genuinely worried about their ex-spouse spying on them. Even if they were all just "paranoid" in their specific cases (I wouldn't know), I think it's a fair concern. If all it takes is some googling and a bit of money to rent cloud GPU's, well, scorned lovers have done way more expensive and less effective things to cause damage or violate privacy.

I've tried setting up WPA2 Enterprise but have been unable to set it up in a way that works with all client hard/software in the enterprise. Windows was especially horrible. Most Linux distros and OSX seemed to kind of Just Work for the most part.

If anyone knows of a WPA2 Enterprise setup guide that works well with minimal hassle (no CA/certificate installation hell, Linux+BSD+OSX+Windows as old as 8), I'd be eternally grateful.

With home security systems being hooked up to WiFi these days and a cost of cracking a WPA password being less than $100 a casual targeted attack isn’t that unlikely.

I'm not disagreeing with you but you might be interested to know that there's a distributed WiFi password cracking project. You can upload packet captures and other people will extract the handshake(s) and volunteer GPUs to crack them. The passwords aren't made available but you can see if someone managed to crack the password.

https://wpa-sec.stanev.org/

I know at least a couple of hackers who cracked other people's wifi, and used a yagi to not just crack their their closest neighbour but someone a bit further away (for safety).

Last time I ran the numbers an ISP default pattern password for ISPs around where I live (assuming perfect randomness within the ISP's pattern) was like $70 on Google Cloud GPUs (with half that on average).

And if your wifi has a default pattern SSID, then it probably has a default pattern password.

$70 is not atrociously high cost for a "last mile" security hop.

And if you have a botnet already then it's free.

These are people who would crack your wifi for the lulz (and have the stolen capacity to do it), get your house raided because they hack companies from behind your Internet connection...

... and then are stupid enough to when they hack and get access to a sensitive government database run a search for their own fucking name... and members of their family.

Not to get into WPA's many failures but purely in terms of auth: At this point WiFi and email auth alone I think is enough reason to learn at least very minimal free MDM for your devices and family devices. I think a fairly significant number of networks fall into the categories private personal (which mainly involve a limited number of specific users and devices), organization (which can handle better auth anyway), or public/guest (which should either be open/"open" or use a portal). In all those cases you can do away with ever needing to manually enter a password via supplying it via a profile, using RADIUS, or a portal, and in turn be free to just have any password itself match 2^256 bits. Even for edge cases I think better distribution strategies make more sense going forward then trying to figure out what an "easy" password can be (and how to rotate it) while still being secure. Just like password managers with websites, we're past the point where we should be using human memory or manual input in general at all.

Can anyone recommend an easy to use MDM for this kind of stuff, for small private use?

Sorry I missed this, though this would probably make for an interesting Ask HN question by itself in terms of what the current best practices are. But for shear simplicity I'd probably start by looking at 1st party solutions: Apple's Configurator 2 and Google's Android Device Manager. macOS was also updated to support mobileconfig files a while back, so you can make profiles to deploy there too. That is probably about as minimal as it gets: simple applications that generate a file which can be distributed over USB or via messages or email and such to set up a range of functions. Setting up a server and command line generation of your own files and such (some tools like the Algo VPN maker will make deployable profiles themselves for ease of use) can be fun, but for a handful of your own private devices with relatively static settings it can be overkill too. A profile may be plenty good enough, and can also just plain save a bit of time by making it easier to load up a bunch of email accounts for example. Also, for the Apple case specifically, they perhaps unsurprisingly expose a lot less functionality in the native mass market user aimed UI then their devices actually support. iOS devices have native support for S/MIME certs for example, but you need to a profile to add them.

Anyway I'd suggest trying those first before digging into server setups or cloud offerings or the like.

There are some statistics on top of this "cloud cracking service" page that might be of interest to you: https://gpuhash.me

Right now it appears they have an 30% success rate (if I'm reading it right).

Interestingly it seems limited to wifi networks that implement the roaming extensions to 802.11. When setting up my network at home with several AP's throughout the house I decided that, whilst roaming is nice, I don't trust most devices to select the strongest AP to latch onto after some trial and error, so disabled it wholesale.

Is this an attack on WPA generally, or just WPA and not WPA2. I don't know if WPA are discrete designs with a common name or an evolution of the same design ala SSL.

The title seems like it's got a typo and WPA2 should be in there along with WPA: "New attack on WPA/WPA using PMKID".

Why say WPA/WPA instead of just WPA? Unless they meant WPA/WPA2.

Correct

So, how secure is a network when the teenagers in the house give out the WiFi key to all their friends when they visit? How secure is it when said teenagers ask Dad to change the previous random-character password to a simple phrase to make it easier for their friends to type it in?

Asking for a friend. :)

In other words, about 99% of the WiFi passwords out there are vulnerable to a brute force attack. But we knew that already, didn't we? Was it not already possible to brute force WPA2 before this new attack?

How much easier/faster is this new attack? It would have been nice if the article itself said something like: "This new attack increases brute force attack rate by a factor of 10x". Or whatever the right value is.

I started to encode it as QR code and share it with guests. It is cross platform :)

Are there any devices with a built-in QR code reader? Android and iOS require a download. Not to mention Windows and Mac.

Do you ask people to download a QR code reader on their devices so they can access your WiFi router? That's a bit too crazy, don't you think?

Latest iOS supports QR codes through a standard camera app, no extra app needed

Afaik, the default camera app on most android installs can recognize/read qr codes.

Never seen one that does this, but I only ever saw a Samsung (from 2012 and 2013), Lenovo (2016), Xiaomi (2018) and Huawei (2018) because my girlfriend and I don't swap them out every other year (heck, not even every four years). I feel like friends might have mentioned it as well, as the topic of a good, FOSS QR code scanner came up a few times in some chats.

Huawei has it, but it's kind of hidden and only accessible from the lockscreen (wtf, right?).

A fun fact I recently discovered when bored and "3D Touching" every app on my phone: Twitter.app has a built in QR code reader. It works pretty well, but I'll concede it might still be crazy to presume guests have the Twitter app installed :-)

edit: oh wow, as sibling commenter points out: the camera app detects QR codes now. neat!

FWIW, 3D touching the Chrome icon also opens a QR Reader.

I'm not sure when/how but all the newer wifi home systems I've seen prompt people's devices to share the password when someone tries to join. So you can have a complex password. Also a lot of those have guest networks so if you need a week network you can have them. Finally you can xkcd your password and make it something like "maytheforcebewithmyfriendmark" - doesn't have to be complex.

This is a feature of iOS and macOS, at least. If you have a wifi network's password saved in your device, you can bring it physically close to another device that doesn't and it will ask whether you want to share. You have to affirm you want to give them the login before it will happen. Very handy when traveling as only one person in the group has to find and (mis)type the password :)

> Finally you can xkcd your password and make it something like "maytheforcebewithmyfriendmark"

No, no, no. The rest of your comment is spot-on, but I've done projects on passphrases and everyone gets this backwards. That is not what XKCD says. Let me quote the XKCD:

> four random common words

Random words, not a phrase like "may the force be with" and "my friend mark" (I'm sure you can find those two online). When cracking public hash dumps using phrases from public sources, I get hundreds of thousands of hits. If your phrase (partially) exists online, it's not a secret one.

Someone else mentioned diceware. Six random words from that dictionary (potentially generated using real dice) is pretty much unbreakable, though it has only a small security margin for when a protocol gets weakened but not broken.

These passwords are not reselient to complicated attacks and are more easily cracked than randomly generated passwords.

Limit the dictionary to the top Xk most common English words, if leetspeak substitution is used you can also easily mask it.

We did this experiment and even randomly generating 6 word passwords using Wikipedia as dictionary resulted in passwords which are faster to crack than 16 character randomly generated passwords and that is because you can’t count the entropy as single characters sure if you brute force it char by char it will take longer but if you use words as your base unit then you only need to find 4-6 from a fairly limited pool of possibilities.

You can further limit it down by using grammar rules if your target is using passphrases those are even faster to crack and can be generated using markov chains or any basic grammar rule engine.

> These passwords are not reselient to complicated attacks and are more easily cracked than randomly generated passwords.

There is no fundamental difference. Either your pool of elements consists of 95 different symbols (ASCII printable characters and space) and you get passwords like 'F~iV3Bcv>\Q@' or your pool of elements consists of thousands of words and you get passwords like 'hubs exempted contend catchment others'.

As per Kerckhoff's principle, we should assume that the method of generating the password is known (which set of elements, i.e. your charset or dictionary, which RNG was used, and perhaps the length of the password).

The resulting strength in terms of bruteforceability of its hash is equal. Assuming one picks sane values, e.g. 6 elements when using a 7800 element set, or 12 elements when using a 95 element set, both are safe to use.

> randomly generating 6 word passwords using Wikipedia as dictionary

I don't understand what you mean by "using Wikipedia as dictionary". Wikipedia contains whole sentences. Did you download a dump of the English Wikipedia and split it on non-word characters and use that as dictionary? Did you remove duplicate words? Or did you take Wiktionary's words?

> if you use words as your base unit then you only need to find 4-6 from a fairly limited pool of possibilities.

I think you're wrong, but feel free to prove me wrong :). Here are some hashes:

    f4cd51713a3ac5798b3a0b40fe61aa2f
    f424f3432b7acbce2c2d3548490c9cc0
    71fa597116bfc54ecc6c48162629d391
    beb09edbc493bf826b61afa6905712df
    42251a29996a78ef023bdb03a8c22ea9
    3a80f15bd82c4f4c0a3338a1fa86adb9

They were generated using this script:

    function genphrase { 
        x=$1;
        while [ $x -gt 0 ]; do
            echo -n $(shuf /usr/share/dict/words | grep -v é | grep -v \' | tail -1)\ ;
            let x=$x-1;
        done;
    }
        
    for i in {1..6}; do
        phrase="$(genphrase $i)";
        sum=$(echo -n "$phrase" | md5sum | awk '{print $1}');
        echo "$sum $phrase";
    done;

Basically I take random words from /usr/share/dict/words so long as it does not contain an apostrophe or an accented e. The md5 hash of the result is generated, a very fast and well-supported algorithm (your favorite cracking program should support it without any trouble). As an example, from another run of the script, here is one of its output lines:

    75e6881687661e09e404b517e7ee2ce3 goodliest villeins gymnast

You can use this sample output to verify that the hash is generated correctly and that your tool works. I expect the first two hashes should not be an issue, the third might be harder, the fourth would be impressive, and I expect that the fifth and sixth will remain uncracked.

The dictionary version is 2018.04.16-1 (wamerican package in Debian), I uploaded it here: https://lucb1e.com/tmp/words (watch out clicking the link, it's a large file and your browser may just display it instead of downloading it)

> You can further limit it down by using grammar rules if your target is using passphrases those are even faster to crack and can be generated using markov chains or any basic grammar rule engine.

At least in my research, I've found that markov chains and n-grams are of much worse quality and slower than just using raw phrases from public sources. The downloading and processing of those sources takes more time, but that's a one-time action and not really part of the cracking process. And as I said in the comment you're replying to, if your 'phrase' is not random words but actually a logical 'phrase', then it's not suitable as passphrase. I think you're confusing random phrases with logical sentences.

The article actually does explain it. The bruteforcing speed doesn't change at all, the same value (PMK) as before is being bruteforced. What changes is merely the approach to get it from the router - an attacker no longer needs to wait for a legitimate user to authenticate, they can ask the router themselves.

It's a little faster because of no nonce error correction shenanigans.

I have a guest wifi network that is isolated from the wifi network that I commonly use... it's probably a bit safer this way.

Guest Wifi. I maintain a strict "guests aren't allowed on the main wifi" rule. The password is 100 characters and if I find a guest on the wifi the password is rotated.

Happened once then they stopped and just handed out the guest password.

Don't give your family the wifi password. Type it in for them. You should be doing the same thing with administrative account passwords. Guests can use guest wifi or plug into the guest switch.

https://github.com/stryngs/scripts/tree/master/pmkid2hashcat

Enjoy =)

Call me paranoid, but my home setup requires a string of 64 hex digits. This is troublesome as some implementations (like the factory setup screen for (old?) versions of Android) cap the input "password" at 63 characters.

Is there any particular reason for this? Even plain case sensitive alphanumeric matches 2^256 bits at around 43 characters. That's should be pretty compatible with even older devices I'd think? Could combine it with some usage of VLANs to segregate different classes of device too, might be extra helpful you have some really legacy stuff you can't do without but that could drag down your network overall.

> 2^256 bits

ITYM 256 bits. :-)

Hah, yeah that written in a rush and went a bit Department of Redundancy Department. Not gonna edit my silliness though, the point was there and I was honestly curious if there was some device out there for which it made a difference. The history is WiFi is so convoluted and implementations so all over the place I'm not sure any level of device weirdness would surprise me at this point, but it could still just be interesting to see exactly how off the rails something could go :)

Seems like an odd choice, why not use a shorter pass with a denser code? I use a rather long (23 character) alphabetic password myself, seems sufficient for my rather uncritical home network.

So why not shorten your password to 63? Will one character really make that much difference if someone is determined to crack your password? And why are you limited to hex digits? Why not use other symbols and characters as well?

A 256-bit pre-shared key is used in WPA authentication. If you type a password, this key is calculated by applying the PBKDF2 key derivation function to the passphrase, using the SSID as the salt and 4096 iterations of HMAC-SHA1. In my case, I am entering the raw PSK manually, so I can't say for sure that some passphrase exists that map to my PSK. Hex digits make it easier to enter this 256-bit binary value and it is a standard way to enter raw PSKs.

Have you considered use of WPA2 Enterprise? EAP-TLS can totally eliminate PSK and all of its problems without extreme approaches.

Just thinking about typing in your PW on a printer makes me shiver.

Mine is really long. My wife almost divorced me over having to put it in some devices with less than desired input mechanisms.

That was what WPS was meant to address. But then everyone left it running 24/7 and a temporary-use tool became a massive backdoor.

The 802.11 standard calls for a passphrase length of 63 characters. Android has it right, whatever you have setup with 64 characters is out of spec.

More detail: https://stackoverflow.com/questions/18006390/why-is-the-wpa2...

It's not a passphrase; it's the raw PSK key as 64 hex digits.

Impressive. Even brute-force attacks eventually get better.

Reply on news.ycombinator.com