6 ms·

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

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.

MadSax 9y ago
Thanks. I also hope that deauth frames are encrypted in the next version of WPA.
- throwasehasdwi 9y ago
  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.
xori 9y ago
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.
- stickfigure 9y ago
  Blocking isn't really necessary. How many attempts could an AP process per second? Not enough to try a large dictionary with variations.
  - phinnaeus 9y ago
    Wouldn't that effectively be jamming the AP at that point?
    - JetSpiegel 9y ago
      At what point you call security, or just look around the room and check who is jamming the WiFi.
- throwasehasdwi 9y ago
  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 9y ago
    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.
    - throwasehasdwi 9y ago
      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_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
    - hueving 9y ago
      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.
    - zeta0134 9y ago
      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.
- deleted 9y ago
  [deleted]

MadSax 9y ago

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

throwasehasdwi 9y ago
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.

xori 9y ago

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.

stickfigure 9y ago
Blocking isn't really necessary. How many attempts could an AP process per second? Not enough to try a large dictionary with variations.
- phinnaeus 9y ago
  Wouldn't that effectively be jamming the AP at that point?
  - JetSpiegel 9y ago
    At what point you call security, or just look around the room and check who is jamming the WiFi.
throwasehasdwi 9y ago
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 9y ago
  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.
  - throwasehasdwi 9y ago
    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_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
  - hueving 9y ago
    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.
  - zeta0134 9y ago
    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.
deleted 9y ago
[deleted]