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).
> 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.
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.
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.
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.
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
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.
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.
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.
...and bring up UI (sandboxed browser) if anything else than expected short 2xx was received.
Step 2) Mobile device reuse same cookies for the same portal second time around, so portal can recognize returning user and let them in without annoying with login prompt each time.
Assuming mobile device has a separate cookie jar for this, and captive portal is HTTPS with proper certificate, and doesn't try to break other people's SSL, that is pretty secure. Sure, this is not the most efficient protocol, but up-side is - it's open-ended. You can fit here anything from "press here if you agree to behave" to complete walled garden like hotspot on a train that shows you interactive map, schedule and transport connections available on the next stop along with small banner asking $1 for full internet access.
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.
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.
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.
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.
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.
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.
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.
The difference between an access point and HTTPS on a web server is that the access point doesn't have an identity to tie the key exchange. You can sprinkle DH here and there to incrementally improve things but it's not going to be bullet proof against active man-in-the-middle attacks.
With things like Lets Encrypt, having each access point own a short lived certificate becomes possible and you can then bootstrap a secure key exchange.
PS: I have no idea which direction WPA3 is going. They might be doing something without certs but a TOFU trust model instead. Either ways, it is possible to design something better than WPA/WPA2 but don't think it's trivial because the constraints aren't the same as existing secure protocols.
>>>The difference between an access point and HTTPS on a web server is that the access point doesn't have an identity to tie the key exchange. You can sprinkle DH here and there to incrementally improve things but it's not going to be bullet proof against active man-in-the-middle attacks.
??? Isnt the MAC address an identity for the AP ?
I always had a doubt about HTTPS . Say Im connecting through a proxy server to a website. The exchange of keys for HTTPS connection happens through this proxy server, means it can capture those and decrypt the connection whenever it wants , right ?
Thanks for your reply.
No, just an address. To be an identity, there must be some way for the AP to demonstrate that it is the right owner of that MAC, otherwise any router can simply copy the MAC.
HTTPS sites do this by getting a CA to vouch for them (in the form of a digitally signed certificate). Tor sites do this by having their address being a representation of their public key, and proving they have the corresponding private key.
I always had a doubt about HTTPS . Say Im connecting through a proxy server to a website. The exchange of keys for HTTPS connection happens through this proxy server, means it can capture those and decrypt the connection whenever it wants , right ? Thanks for your reply.
No, thanks to Diffie-Hellman[1], you can exchange keys with a remote server over a non-secure channel in a way that anyone listening can't figure out the key.
Of course, this happens after the server has proven it is who it says it is, by using one of the methods above. Otherwise, the proxy could pretend to be the server, and exchange keys itself with you.
You can have bulletproof protection against MITM as long as you have a shared secret so it's possible with wifi. The other answers in this chain about PAKE have details.
It is correct that HTTPS and other protocols generate temporary keys for each connection but there's another much older reason why this is done, particularly for TLS.
Asymmetric encryption algorithms are, in general, orders of magnitude slower at encryption than AES. With these protocols the initial secure connection is done using asymmetric cryptography. It makes sense to use the established secure channel to exchange another set of keys and switch over to AES or another symmetric algorithm immediately.
Nowadays the two ends negotiate a key exchange to allow things like perfect forward secrecy as well, so this is becoming a historical footnote to an extent.
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.
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.
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.
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.
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.
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
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.
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
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.
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.
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".
shuf is not a crypto tool, and the GNU coreutils are written to be cross-platform, even where /dev/urandom doesn't exist, or is unreliable. That's my guess, at least.
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)
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.
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
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.
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.
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?
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.
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?
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.
>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.
I attempted to do this once and it turned out to be monumentally difficult. I got as far as setting up a bootable kali thumb drive before getting stopped in my tracks by hardware incompatibilities and unexpected behaviors and errors. These articles make it sounds a LOT easier than it is. I was very disappointed because I was really excited about it.
It's not for the faint of heart or faint of technical skill - different drivers have different behaviors and ways to enter the various capture and raw packet modes needed to do this.
Personally, as long as I stick to supported chipsets, I've almost never had an issue.
I've had great luck with this wireless card. Works out of the box on any linux distro I've used it with. I bought it specifically for its aircrack compatibility (packet injection and monitor mode).
Not all Alfa products are OOB compatible, you definitely need to be careful. I have the AWUS036AC which requires compiling a DKMS module.
It was a pain the get working on my Raspberry Pi, I had to try several different drivers and edit a Makefile to get it to compile. But I did eventually get it working as an AP, there's a script called create_ap which is very nice to painlessly run an AP on Linux.
I tested some of the most popular Kali Linux compatible cards against each other here[0]. Note that there is a version 2 of the popular and cheap TP-Link TL-WN722N which DOES NOT work like the version 1 and should be avoided.
All of these cards are "known to just work" on linux at least.
I beg to differ. I was doing this at 15 or 16 years old in 2006 when it was still called backtrack. So long as you had a mainstream laptop, the most difficult part was buying a compatible wireless card.
To note, the extent of my technical abilities at that time wasn't much beyond being able to install a mainstream linux distribution or write a simple program in C.
Regrettably it didn't work out that way for me. I had a brand new macbook air at the time I tried this. When I booted into Kali, I was unable to access the network settings at all[1], period, let alone get any packet sniffing going. I couldn't even connect to the internet.
Thanks for the nostalgia trip. We must be about the same age and I remember hitting up local corporations that had WEP encrypted networks and offering them my help in improving their security.
Felt like a real security expert then ;) I'm out of that loop now but security sure did seem a lot easier to get a grip on at that time.
When I was in school and taking some network security classes I attempted to crack my own wifi. Even after buying a wifi card that could do what I need I faced hardware isssues. It was a major PIA.
It was almost easier to automate a brute force, sit back and wait.
And to make matters worse the compatible hardware has been counterfeited a thousand times over and you never know which one you're going to get purchasing online.
4,733,979 out of the 14,344,391 passwords (33%) in the rockyou.txt dictionary file used for cracking in this guide are too short to be WPA2 passwords, which have a minimum length of 8 characters. Are aircrack and/or hashcat smart enough to not bother hashing those short passwords?
hashcat is smart enough in a subtle way. It will not bother with candidates that are unsuitable for a certain hash type.
It checks this after the rules have been applied.
(stusmall's comment explains the influence of rules better than I could). Hashcat shows these candidates as "Rejected".
The interesting part is that you can't configure the minimum or maximum length anymore[1], the restrictions are hard coded for every hash type. This is because for fast hashes the branch introduced by the check would be slower than just hashing away[2].
[1] It was possible with the old CPU-based hashcat (--pw-min and --pw-max)
They don't touch it in this tutorial but typically you don't check just whats in your dictionary. You also use a set of rules to manipulate your dictionary that massively increases the number of hashes to perform. Those 5 million entries quickly passes tens of billions hashes that need to be run. These initial entries might be too short like OP pointed out, but after the rules are applied it might generate many entries that will be long enough to spend time hashing.
The keyspace for WPA is huge and the hash speed is still relatively slow, even with an extremely high end system like you linked to the quality of the initial dictionary is really important.
I had the idea a long time ago to make a dd-wrt image which would automatically crack the vulnerable routers within distance, detect the model, and install a compatible version of itself in order to spread virally and create a mesh network. I'm not going to pursue it because it probably breaks a lot of laws, but I'm still curious if it would have been possible. Does anyone know if this is actually feasible? Maybe the radios can't handle that sort of thing?
That certainty breaks the Computer Fraud and Abuse Act, and while impractical, I think you could be charged separately for cracking each router. That said, interesting idea. If I were to do it, I wouldn't crack the passwords on the router itself, but rather attach 3G hardware to the router to "phone home" captured handshakes and run your cracking on GPUs in the cloud, sending results back to the router.
To the script kiddies out there who read this: Do not try this on others wifi. It is a crime in the USA to crack network routers. Although the chance of you getting caught is low, better be safe than sorry.
> It's not illegal to receive signals on an unlicensed band with stock equipment
But my neighbors would still be pretty miffed, and would likely have legal recourse, if I passively captured their EM emissions in the 390-700nm band through their bedroom windows at night on a regular basis.
>You're not hacking into anything, simply observing.
Technical distinctions don't always map onto legal distinctions. Even if you're eventually acquitted, how much do you want to pay yourself per hours to explain this to a judge?
Technically using iodine to tunnel via DNS on captive portals is also illegal (I think .. although I'm not sure if anyone has been prosecuted for this .. IANAL)
IANAL, but from reading for a little bit, it seems to vary and states have their own laws.
There's some discussion on Wikipedia here[2] of unauthorized piggybacking (which does not even require hacking the network), with a few examples of actual instances.
In St. Petersburg, 2005, Benjamin Smith III was arrested and charged with "unauthorized access to a computer network", a third-degree felony in the state of Florida, after using a resident's wireless network from a car parked outside.
A third-degree felony in Florida seems to be up to 5 years. In some states it is up to 10 years. Another person got "a fine of $250 and one year of court supervision".
If it's unauthorized access to the computer of a government or financial institution (or "which is used in or affecting interstate or foreign commerce or communication", which can be interpreted very broadly), then the Computer Fraud and Abuse Act would apply[2]. From reading about the sections regarding "trespassing", punishment can be a fine and 1-5 years imprisonment (first offense), or up to 10 years (repeated offense).
The deauthentication packet looks interesting. Does that mean, that I could annoy the hell out of my neighbors by constantly forcing all of their devices to reconnect?
How long does the cracking process take? I remember WEP only taking 10 minutes using aircrack-ng in BackTrace... I imagine this takes substantially longer.
Yeah, which is why it is sometimes weirdly safer to not change your SSID - a cracker can assume that someone who figured out how to change the broadcast name could've also changed the WiFi password... often to something much less secure.
So I don't have experience with WPA cracking, but if the access point has WPS (the click to connect button) you can sniff handshakes on the network and crack the WPA password it in relatively no time. In my experience this has usually been under 10 minutes.
>Naive-hashcat uses various dictionary, rule, combination, and mask attacks and it can take days or even months to run against strong passwords. The cracked password will be saved to hackme.pot, so check this file periodically.
The DSL provider in my area sets up customer's wireless networks with their home or mobile phone number as the password. If you know that number or can look it up in public records then you're in. If you can't find it maybe use a dictionary pertaining to the area code of phone numbers and then you're in. When the protocol changes to something more secure, the ISP's customer will still be as insecure as they always were.
That's not as bad as deriving password and SSID (Provider-$generated_number) from the MAC address, it didn't take much for somebody to reverse the algorithm from the bootloader and make various programs to calculate the few possible password from SSID
Does this only crack single word passwords? If my password was two common dictionary words or a common word plus a single number, would this try that possibility?
Using a wordlist with aircrack-ng seems to only try the literal passwords in the dictionary. If you use naive-hashcat, a series of dictionary, rule, combination, and brute-force attacks will be used. I recommend reading up on the hashcat wiki (https://hashcat.net/wiki/) to learn how to conduct your own custom hashing attacks.
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).
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.
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.
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.
Step 1) For mobile device to make a request to a special URL that is known to respond with short 200/204, something like that:
...and bring up UI (sandboxed browser) if anything else than expected short 2xx was received.Step 2) Mobile device reuse same cookies for the same portal second time around, so portal can recognize returning user and let them in without annoying with login prompt each time.
Assuming mobile device has a separate cookie jar for this, and captive portal is HTTPS with proper certificate, and doesn't try to break other people's SSL, that is pretty secure. Sure, this is not the most efficient protocol, but up-side is - it's open-ended. You can fit here anything from "press here if you agree to behave" to complete walled garden like hotspot on a train that shows you interactive map, schedule and transport connections available on the next stop along with small banner asking $1 for full internet access.
[0]: http://www.zytrax.com/books/dns/info/minimum-ttl.html
For IE, you can just refuse connections to the internal webserver for logged in users, as IE will then mark those IPs as bad and refresh the DNS: https://blogs.msdn.microsoft.com/ieinternals/2012/09/26/brai...
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.
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.
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.
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.
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.
With things like Lets Encrypt, having each access point own a short lived certificate becomes possible and you can then bootstrap a secure key exchange.
PS: I have no idea which direction WPA3 is going. They might be doing something without certs but a TOFU trust model instead. Either ways, it is possible to design something better than WPA/WPA2 but don't think it's trivial because the constraints aren't the same as existing secure protocols.
??? Isnt the MAC address an identity for the AP ?
I always had a doubt about HTTPS . Say Im connecting through a proxy server to a website. The exchange of keys for HTTPS connection happens through this proxy server, means it can capture those and decrypt the connection whenever it wants , right ? Thanks for your reply.
No, just an address. To be an identity, there must be some way for the AP to demonstrate that it is the right owner of that MAC, otherwise any router can simply copy the MAC.
HTTPS sites do this by getting a CA to vouch for them (in the form of a digitally signed certificate). Tor sites do this by having their address being a representation of their public key, and proving they have the corresponding private key.
I always had a doubt about HTTPS . Say Im connecting through a proxy server to a website. The exchange of keys for HTTPS connection happens through this proxy server, means it can capture those and decrypt the connection whenever it wants , right ? Thanks for your reply.
No, thanks to Diffie-Hellman[1], you can exchange keys with a remote server over a non-secure channel in a way that anyone listening can't figure out the key.
Of course, this happens after the server has proven it is who it says it is, by using one of the methods above. Otherwise, the proxy could pretend to be the server, and exchange keys itself with you.
[1] https://security.stackexchange.com/questions/45963/diffie-he...
Asymmetric encryption algorithms are, in general, orders of magnitude slower at encryption than AES. With these protocols the initial secure connection is done using asymmetric cryptography. It makes sense to use the established secure channel to exchange another set of keys and switch over to AES or another symmetric algorithm immediately.
Nowadays the two ends negotiate a key exchange to allow things like perfect forward secrecy as well, so this is becoming a historical footnote to an extent.
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...
I feel like the initial key exchange should be done with something most resource intensive than elliptic curves.
I need to be in the baseline standard to get qualified or nobody will implement it.
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.
The problem with ECDH here is that group elements aren't just numbers.
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.
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
It's all about the length really.
Is 10 characters considered weak for mixed case letters, numbers, plus punctuation now?
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
https://duckduckgo.com/?q=pwgen+strong+10&ia=answer
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
Most password crackong dictionary already include common keyboard patterns sich as "qwerfdsazxcv" or variations of it.
Making a phrase is okay, but you have to start with actually-random words.
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".
https://www.gnu.org/software/coreutils/manual/html_node/Rand...
https://sockpuppet.org/blog/2014/02/25/safely-generate-rando...
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)
Edit: As another comment said, just make sure it's not easy to guess based on rainbow tables and whatnot
(And could / should we include somehow that "hashes/second" increases by factor of ~2(?) each year?)
However definitely DONT use a quote or lyrics. Needs to be something unique.
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.
Spelling words correctly is not "arbitrary", it's conventional.
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.
Any advice for what constitutes a strong or weak password in this context?
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.
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.
Just look for a wordlist in the respective language or also try to create your own via tools like CeWL?
Personally, as long as I stick to supported chipsets, I've almost never had an issue.
https://www.amazon.com/Alfa-AWUSO36NH-Wireless-Long-Rang-Net...
although some of the reviews seem to indicate there may have been a change in chipset/drivers. I wish you luck!
It was a pain the get working on my Raspberry Pi, I had to try several different drivers and edit a Makefile to get it to compile. But I did eventually get it working as an AP, there's a script called create_ap which is very nice to painlessly run an AP on Linux.
https://tehnoetic.com (EU)
https://www.thinkpenguin.com (USA)
just works.
All of these cards are "known to just work" on linux at least.
[0] http://rooftopbazaar.com/wirelesscards/
To note, the extent of my technical abilities at that time wasn't much beyond being able to install a mainstream linux distribution or write a simple program in C.
On a pretty standard laptop (intel chipset/CPU/GPU/Wireless) it booted right up with no effort.
[1] https://unix.stackexchange.com/questions/273941/missing-netw...
Felt like a real security expert then ;) I'm out of that loop now but security sure did seem a lot easier to get a grip on at that time.
It was almost easier to automate a brute force, sit back and wait.
The interesting part is that you can't configure the minimum or maximum length anymore[1], the restrictions are hard coded for every hash type. This is because for fast hashes the branch introduced by the check would be slower than just hashing away[2].
[1] It was possible with the old CPU-based hashcat (--pw-min and --pw-max)
[2] https://hashcat.net/forum/thread-3444.html?highlight=branch
The keyspace for WPA is huge and the hash speed is still relatively slow, even with an extremely high end system like you linked to the quality of the initial dictionary is really important.
http://gizmodo.com/264050/slurpr-wi-fi-box-sucks-up-six-sign...
Not trying to say that easier is better, in this case. Just wanted to show this tool for those who don't know it.
[1] - https://github.com/derv82/wifite2
edit: added wifite initially, replaced it with wifite2
It's not illegal to receive signals on an unlicensed band with stock equipment
But my neighbors would still be pretty miffed, and would likely have legal recourse, if I passively captured their EM emissions in the 390-700nm band through their bedroom windows at night on a regular basis.
Technical distinctions don't always map onto legal distinctions. Even if you're eventually acquitted, how much do you want to pay yourself per hours to explain this to a judge?
There's some discussion on Wikipedia here[2] of unauthorized piggybacking (which does not even require hacking the network), with a few examples of actual instances.
In St. Petersburg, 2005, Benjamin Smith III was arrested and charged with "unauthorized access to a computer network", a third-degree felony in the state of Florida, after using a resident's wireless network from a car parked outside.
A third-degree felony in Florida seems to be up to 5 years. In some states it is up to 10 years. Another person got "a fine of $250 and one year of court supervision".
If it's unauthorized access to the computer of a government or financial institution (or "which is used in or affecting interstate or foreign commerce or communication", which can be interpreted very broadly), then the Computer Fraud and Abuse Act would apply[2]. From reading about the sections regarding "trespassing", punishment can be a fine and 1-5 years imprisonment (first offense), or up to 10 years (repeated offense).
1: https://en.wikipedia.org/wiki/Legality_of_piggybacking#Unite...
2: https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act
I did a study using an Atom netbook - a 64 bit key (10 digits long) took 8 mins to find, 128 (26 digits) took 30 mins
Also to reduce the size of the pcap file, you may want filter it for EAPOL packets only:
tshark -r input.pacp -R "eapol || wlan.fc.type_subtype == 0x08" -w small.pcap