[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.

[hunter2_]

Aside from custom root certs being installed, https is out either way, not only with IP address, right? HSTS makes that even more of a problem, and pinning makes even the custom root cert a problem. Captive portals seem like an increasingly fragile idea, except that OSes increasingly intervene appropriately.

[icebraining]

You just reply to any DNS request with your own server's IP, which accepts any HTTP requests with a redirection to the captive portal. The replies can have low TTLs to avoid the caching problem.

[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.

[zeta0134]

This is a reasonable guess at how encryption works, but it's also flawed. The key you need to crack on a Wireless Router isn't the key that's used for actual encryption of data, but rather the key used to set up that encryption in the first place.

Basically, your keys are used to handshake with the access point, and then exchange a new set of temporary keys for the duration of your connection. These temporary keys (which are exchanged during the handshake, and encrypted by something which involves your original keys) are then used to encrypt user data.

Because the data are encrypted with new keys for each connection, and those keys aren't based on the original keys in any way, knowing the plain text version of the data you're trying to decrypt doesn't help. You might be able to recover the temporary key, but you can't use this by itself to join the router, and the key is thrown away when that user makes a new connection. (These keys are also usually quite large, random, and very resistant to brute force methods anyway.)

HTTPS works similarly, and it needs to, because many (many!) websites start with the plain text "<html" which would make it trivial to brute force the keys offline otherwise.

[throwasehasdwi]

I'm not a crypto expert and I'm sure even if I was it would be difficult to explain. Wiki page on SRP has a good description though:

Like all PAKE protocols, an eavesdropper or man in the middle cannot obtain enough information to be able to brute force guess a password without further interactions with the parties for each guess.

In layman's terms, given two parties who both know a password, SRP (or any other PAKE protocol) is a way for one party (the "client" or "user") to demonstrate to another party (the "server") that they know the password, without sending the password itself, nor any other information from which the password can be broken. Further, it is not possible to conduct an offline brute force search for the password.

https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...

[xori]

To clarify, I agree that the individual connection key is safe from brute force. But I feel like the initial shared key is vulnerable. I doubt you'd get MITM on your connection, but you can still get a bad actor on your network.

I feel like the initial key exchange should be done with something most resource intensive than elliptic curves.

[hueving]

Knowing the plaintext version of a packet does not allow you to get the key. That's called a known plaintext attack and AES is resistant to it.

[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?

[JetSpiegel]

At what point you call security, or just look around the room and check who is jamming the WiFi.

[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.