[throwasehasdwi]

I'm not sure why this is amazing enough to make the first page but W/E it's HN :). Just so less informed are aware, this has been feasible for maybe 7 years (since GPU calculation became possible).

Just so nobody freaks out, this is cracking weak passwords, not broken WPA.

I have myself cracked countless WiFi passwords when security testing. It's easy if the passwords are bad, which is maybe 90% of the time for home networks and 60% for businesses. The attack is completely passive if you don't want to be noticed, and with a cheap dish you can pickup both ends of the handshakes from up to around a quarter mile away (line of sight).

[amluto]

> Just so nobody freaks out, this is cracking weak passwords, not broken WPA.

I beg to differ. The fact that WPA is subject to a passive attack at all is a defect. It should use a PAKE, which would entirely avoid this type of attack.

There are simple balanced PAKE protocols that would do the trick. DH-EKE, SPAKE2, J-PAKE, and even the venerable SRP would all work. I believe that several are old enough that no patents are possible, and, even when WPA was standardized, something should have been available.

[throwasehasdwi]

Yes, this is still a major problem with WPA. Also the fact that certain control packets aren't authenticated is nearly unforgivable. If correctly designed the only reasonable attack on wifi would be channel jamming, sadly after many years this still is not the case.

[d33]

This is probably a good occasion for a call for WPA3: https://github.com/d33tah/call-for-wpa3

[kees99]

WEP, WPA, WPA2... why keep reinventing the same wheel? Each new iteration inevitable turns out to be less-than-perfect and keep adding more and more complexity and overhead - for one, join/leave times keep increasing, up to a point where we have a separate standard (802.11r) just to get back pre-WPA roaming speeds (at cost of even more protocol complexity overhead).

Here's crazy idea: Why not run open network + IPSEC, or heck, even OpenVPN? Obviously, drop all non-VPN traffic right on the AP (or first router after it) to nip freeloaders in the bud.

[d33]

IPSec and OpenVPN are complex like hell and not very well supported across OSes (think of the UI too). This is why I'm waiting for Wireguard.io, it looks like a step in a good direction.

[zx2c4]

I've been experimenting with this exact kind of network setup -- open WiFi that only allows packets to and from the WireGuard endpoint. The nice part is that it means I just have WireGuard on all the time, and because it roams, when I connect to a different WiFi networks, I remain on my home network automatically. I've also been putting my actual wlan0 interface in a separate namespace, isolated from real things. This way there's no chance of leaking data: https://www.wireguard.com/netns/#the-new-namespace-solution

[djsumdog]

Most captive portal routers don't block DNS (because they use iptables rules to handle authentication). That's why you can use iodine to proxy TCP-over-DNS on such APs. So if you just had an open access point, unless you provided no DNS servers except over VPN, people would still be able to use your AP.

[poizan42]

Presumably you want to reply to DNS requests for a hostname for your captive portal. You might try to just use a raw ip address, but then you can't use https. So then you have the problem that you can't just reply with a fake answer for other domains due to caching. E.g. Windows caches negative responses for 5 minutes, which would be a pretty bad experience for your customers.

I guess you might be able to just fail to reply to DNS requests for domains outside you captive portal, I have no idea if anyone has tried that or there might be other complications.

Edit: Actually not replying wouldn't work great either because then the user can't be redirected to the captive portal. This might be less of an issue today since most devices have standardized a way to detect captive portals using a small set of hostnames.

[kees99]

Newer captive portals (FON with latest firmware for example) are blocking iodine by being clever about which request to answer (bunch of A and AAAA with some of responses being CNAMEs, which are quickly followed by resolution of just received answers to A/AAAA), and which to block (bunch of NULL queries or "dangling" CNAMEs that are not followed by A/AAAA).

That being said - that's a bit over the top. The only reason I wouldn't want my AP to be open and unfiltered is - I don't want any junk being sent out which is attributable to me (by IP), and which I have no control over. Iodine, being a tunnel will only transport to "guest"'s server and go into the wider Internet with their server's IP.

If somebody is in enough of a squezze to jump over that sort of hoops, and there're no costs/risks for me - let them have it. I'm fine with that.

[MadSax]

For those that don't know, like me, how would PAKE etc protect cracking of weak passwords used during client authentication?

[throwasehasdwi]

It doesn't give you a hash to crack. It reduces your speed of guessing passwords from "how quick can you hash X", which is millions of times per second, to "how many times can I attempt to get in before the access point blocks me".

This major issue with WPA password cracking today is that it can be done "offline". You can pull the handshake out of the air and bang on it as long as you want. It's pretty much the same thing as trying to guess a password from some leaked hashes vs trying to guess a password using the gmail interface.

[xori]

I'm not sure how PAKE works, but how would an AP block you? MAC address are forgeable. And any nonce an AP sends down as a one-time salt would be visible to you and you could still just brute force it offline.

EDIT: After reading up on SPAKE2, it's basically just a Diffe-Hellman exchange. You can still totally do a brute force because you know what the first encrypted payload should look like and you can listen in for that encrypted message and use that as your "test that you got it right"

I think that at the end of the day, no matter what key stretching techniques you use. A bad starting key results in a bad end key.

[throwasehasdwi]

You can't brute force a nonce offline when you don't know if you answer is right unless you ask the AP. Different protocols than sending hashes where you can tell if your hash is correct just by looking at it.

You are right that the AP couldn't block you without blocking everyone, but since you need to check your answer with the AP for each guess your attack becomes extremely visible. I guess you could still DDOS the AP by sending auth requests faster than it allows but that doesn't hurt the channel any more than barrage jamming which is un-blockable.

[xori]

But you can capture the first encrypted packet from the router, and you know what the protocol is to test if your decoded version is correct. I still don't see how this helps.

[stickfigure]

Blocking isn't really necessary. How many attempts could an AP process per second? Not enough to try a large dictionary with variations.

[phinnaeus]

Wouldn't that effectively be jamming the AP at that point?

[MadSax]

Thanks. I also hope that deauth frames are encrypted in the next version of WPA.

[throwasehasdwi]

They are a current feature but not the baseline which means in practice implementations are buggy or non existent. I've had a few nicer routers where I could turn the options on but most clients are not able to connect :( .

I need to be in the baseline standard to get qualified or nobody will implement it.

[mrb]

PAKE is awesome, yet not very well-known :-( In a nutshell a PAKE scheme guarantees that (1) a passive attacker has no way to brute force passwords at all, and (2) that an active attacker can at most test one candidate password per authentication attempt.

PAKE is used by Thread (IOT protocol built on top of IEEE 802.15.4: https://threadgroup.org/ and it's precisely its use of PAKE that makes it one of the most secure wireless protocols IMHO. Disclosure: I helped security-review it during its design.) Various PAKE schemes exist but a simple one based on Diffie-Hellman works like this (called DH-EKE):

1. Client selects random priv, pub key pair: a, g^a

2. Server selects random priv, pub key pair: b, g^b

3. Client sends its pub key encrypted with client's password: E(g^a, passwd)

4. Server sends its pub key encrypted with client's password: E(g^b, passwd)

5. Client and server each decrypts the packets (with the password that they both know) and get each other's pub keys: g^a, g^b

6. Client and server proceed with standard Diffie-Hellman: they compute g^ab use this value as an encryption key

7. Client and server do a message exchange encrypted with g^ab, to verify they both derived the same key.

Note: I demonstrate the scheme DH-EKE because it's simple. But please know this scheme is flawed when naively implemented. In theory it should be safe when used with an elliptic curve variant using Elligator https://elligator.cr.yp.to/ but I haven't seen much research and peer reviews of Elligator... Other PAKE schemes are considered perfectly secure (but their complexity makes them unsuitable to be explained in an HN comment, eg: J-PAKE.)

What can an "offline" attacker do? He can passively sniff the packets and get E(g^a, passwd) and E(g^b, passwd) but there is no way for him to bruteforce the password. He can try to decrypt the packet with candidate passwords, but he does not know when he guesses the right one, because a successful decryption will reveal g^a or g^b however these value are indistinguishable from random data (when using Elligator because that's exactly what it guarantees: that a pub key is indistinguishable from random data.) And even if he guessed right, he would obtain g^a and g^b, but would not be able to decrypt any further communications as the use of Diffie-Hellman makes it imposible to calculate the encryption key g^ab.

What can an "online" attacker do? If he actively MiTM the connection and pretends to be the legitimate server, he can send his own E(g^b, passwd) to the client using one guessed candidate password. If he guessed wrong, then the client will decrypt to an incorrect g^b, will not calculate the right g^ab, and step 7 will fail. Good. At least the client can detect a (failed) password guess attempt. And that's all the attacker can do. Each authentication attempt gives him only 1 chance to test 1 password. If, out of frustration, the client tries to retype the password and re-auth 3 times, then the attacker can at most try to guess 3 candidate passwords. He can't bruteforce many passwords.

An effort is ongoing to standardize one of the PAKE schemes, called J-PAKE, in TLS: https://www.ietf.org/archive/id/draft-cragie-tls-ecjpake-01.... TLS with J-PAKE is what Thread uses.

[amluto]

You don't need Elligator to make DH-EKE work - you can do it with old-fashioned DH. The property you need is roughly that D(E(g^a, pw), guess) has the same distribution regardless of whether pw == guess. If the group is Z_p and g generates the whole group, then E could be a pseudorandom permutation of [1,p-1].

The problem with ECDH here is that group elements aren't just numbers.

[throwaway91111]

Agreed. However, WPA has been obviously broken for years; just use WPA2 instead. It's also way easier to set up on your grandmother's random router.

[lqdc13]

Nowadays most routers I've seen come with a pre-shared key that's something like 20 chars long.

It's been the case with Comcast + Verizon for a while now. Not sure about AT&T.

Still might work 10% of the time though.

[paulgerhardt]

Some regional bias here.

Most of Asia (so most of the world) use digits only for their wifi password.

Lack of fluency with Latin characters was not a big concern in the original implementation. That should be fixed with WPA3

[lqdc13]

Why does that matter? 15 character digits-only password is impossible to crack really.

It's all about the length really.

[mdeeks]

Can someone define what is considered a weak vs strong password now for WiFi? The only guides I found online are years old.

Is 10 characters considered weak for mixed case letters, numbers, plus punctuation now?

[rocqua]

To do this formally, you need to consider information entropy. This is all about how you generated your password. 10 characters of totally random mixed case, numbers and punctuation gives about 60 bits of entropy which is strong enough.

HOWEVER, that calculation only works if all 10 characters were generated uniformly and randomly. Humans are terrible at this. Now, maybe your trick for turning words into safe passwords is great, but there is no way to be sure. Sadly, remembering 10 random characters is hard.

Luckily, easy to remember and strong passwords are possible. The system I would recommend is diceware: www.diceware.com

[column]

That diceware system is complete Snowden-level paranoia. Close the curtains! Burn after reading! For everyday techie joe a passphrase + a memorized complex password is just enough. If you're on the internet asking for a strong password method and reading diceware.com you may have your priorities set wrong like an untrained spy.

https://duckduckgo.com/?q=pwgen+strong+10&ia=answer

[samstave]

I would love to see a comparison between where physically and which modifiers are used for each character are, and the strength of a password.

Is a password which is very easy/comfortable to type out physically any more/less strong than another of the same length?

I ask this because I often use a visual pattern on the keyboard for a password and I don't recall which characters they may be, but I recall the pattern in need to type out on a qwerty kb

[Laforet]

Depends on how good the pattern is, however entropy is lower all likelihood because the layout of qwerty keyboard is standardised.

Most password crackong dictionary already include common keyboard patterns sich as "qwerfdsazxcv" or variations of it.

[joshjje]

There was a nice comic/picture of this. I tend to follow it. Basically using 3-4 short words as a phrase instead of random characters. You can toss special characters inbetween/before/after. They are also much easier to remember. Password "FoolMeOnce!ShameOnMe" for example.

[Dylan16807]

But you've gone and picked only one preexisting phrase, instead of independently-random words. That cripples the security of your password.

Making a phrase is okay, but you have to start with actually-random words.

[joshjje]

Well, it was an example, but I agree. For everything that I can I use keepass with better autogenerated random passwords, but for things like home WiFi and others that I may have to type in manually I'll use a phrase like this. A more random phrase is certainly more secure.

[freeflight]

For completeness sake, this is probably the comic you are referencing: https://xkcd.com/936/

[shpx]

    curl -s https://raw.githubusercontent.com/first20hours/google-10000-english/master/google-10000-english-no-swears.txt | shuf | head -n 4 | tr '\n' ' '; echo
    mine wear vacation mostly

log2(10^16) = 53 bits of entropy or 300 years if your attacker can do a million guesses per second (the link says 1000 keys per second, but that's on the CPU).

You could also use `cat /usr/share/dict/words` instead of the `curl`, which is a much larger word list, but you get impractical passwords like "globular cellulose's malnutrition's dangling".

[icebraining]

Careful, shuf is not cryptographically safe by default! You need to pass --random-source=/dev/urandom to get a proper RNG.

https://www.gnu.org/software/coreutils/manual/html_node/Rand...

[joshjje]

Nice, yes that was the one, thanks.

[throwasehasdwi]

Wifi password cracking is only around 1000X slower than a SHA256 brute-force if I remember right. So your password needs to be secure enough that if a hash of it was leaked it would never be cracked.... So very strong.

WPA enterprise using certificates is usually much harder to crack since you need to interrogate server, you can't just brute force hash. This method only really applies to PSK mode (home networks and small businesses usually)

[fhood]

Weak = is in rainbow table that hashcat is using

[Dylan16807]

That should be enough, but keep in mind that you might be entering the password on a lot of non-keyboards. 20 lowercase letters is faster and far more secure. Even 14-15 lowercase letters is soundly better.

[domenukk]

If you consider your random keyspace with 26 * 2 chars + 10 numbers + 20ish special chars then to crack 10 letters you'll have to try an average of ((26 * 2 + 10 + 20) ^ 10) / 2 = 6.8724016e+18 keys. If you then assume around 3 million hashes per second it still takes around 72641 days to crack your password.

Edit: As another comment said, just make sure it's not easy to guess based on rainbow tables and whatnot

[1wd]

Did you mean 72641 days or years?

(And could / should we include somehow that "hashes/second" increases by factor of ~2(?) each year?)

[slackingoff2017]

I read in many places that the easiest way to generate a really strong password is to memorize a fairly long sentence and use the first letter of each word.

However definitely DONT use a quote or lyrics. Needs to be something unique.

[thomastjeffery]

> but W/E it's HN

Would you please simply type "whatever", instead of this "W/E" nonsense? Considering the amount of 8+ character adjectives you used, you clearly aren't trying to be less verbose.

[Markoff]

i am not native speaker so didn't even know what does it mean, since it's much less common than Without written this way

[hyperdunc]

In the same spirit of improving grammar and readability - I think you meant to type 'number' of 8+ character adjectives.

[melq]

You understood him perfectly well, what exactly is your criticism? If he agrees to comply to your arbitrary standards of style, only to say the exact same thing, will you agree to "please simply" refrain from being obnoxious for no reason?

[frankzinger]

> arbitrary standards of style

Spelling words correctly is not "arbitrary", it's conventional.

[thomastjeffery]

I did not understand perfectly well.

Understanding for me required a Google search. It's quite a nuisance for me to have to google an uncommon abbreviation for one of the most common words in my native language.

[hartator]

I am okay with abbreviations, but I had to think twice for this one.

[TheAceOfHearts]

In your opinion, is setting up a RADIUS server and using WPA2-Enterprise worth it for a consumer? I'm pretty paranoid, and also think it could be an insightful experience to tinker around with networking tools.

Any advice for what constitutes a strong or weak password in this context?

[ComputerGuru]

I wanted to do that in my home, but good luck getting IoT devices to connect which may be a good thing..)

You'd probably have to set up a separate network for those devices (again, technically a good thing) which can be a source of some friction.

It used to be only good routers had a guest network option, but now even $20 TP-Links can use Radius for the main network and WPA2 for the guest network; though I'm not sure you can do something like whitelist by MAC on only the guest network.

[pixl97]

>In your opinion, is setting up a RADIUS server and using WPA2-Enterprise worth it for a consumer?

It can be a pain in the ass when the consumer device requires a valid SSL certificate. On active directory networks this isn't much of a problem because a CA is pushed out to devices, but automating this at home can be a bigger issue.

[daurnimator]

dynamic dns + letsencrypt?

[cpach]

~15 random characters (printable ASCII of course) should be enough for a WPA2 password.

[jagermo]

If I might ask, how would you compile a password list for a non-english speaking country?

Just look for a wordlist in the respective language or also try to create your own via tools like CeWL?