Slashdot Mirror
WPA2 Wireless Security Crackable WIth "Relative Ease"
An anonymous reader writes "Achilleas Tsitroulis of Brunel University, UK, Dimitris Lampoudis of the University of Macedonia, Greece and Emmanuel Tsekleves of Lancaster University, UK, have investigated the vulnerabilities in WPA2 and present its weakness. They say that this wireless security system might now be breached with relative ease [original, paywalled paper] by a malicious attack on a network. They suggest that it is now a matter of urgency that security experts and programmers work together to remove the vulnerabilities in WPA2 in order to bolster its security or to develop alternative protocols to keep our wireless networks safe from hackers and malware."
This sounds like the classic de-auth, handshake capture, then brute force attack.
It's still a bitch to crack without G.O. resources. Moxie has a service that will try for you...
Reads article...
Longer passwords make brute force cracking more difficult... Possible attack vector via the wireless de-authentication and re-authentication that WPA2 connections maintain for clients... With potential fast scanning and proper spoofing, an intruder could knife their way it...
Why does this feel like nothing new?
How do you keep something you never had?
“He’s not deformed, he’s just drunk!”
Once quantum computing fully arrives, I guess encryption will be mostly moot.
Bad guess
Someone had to do it.
Brute force attacks compromise simple passwords?
This is news?
_ _ _ Go for the eyes Boo! GO FOR THE EYES!
The only reason I encrypt my wifi connections is to prevent casual wanderers from connecting to my network and sucking up bandwidth. Any data that needs securing is encrypted by the computer, not by the modem/router.
If I could get proper password protection without the encryption, I wouldn't bother encrypting the traffic. I could care less who snoops it -- so long as they're not sucking up bandwidth.
I do not fail; I succeed at finding out what does not work.
Can't tell what exactly the paper is about due to a paywall and the fact that the article was written by someone not very techincal.
EAP-TTLS, as long as you are validating the server certificate, is pretty safe. Safer with a locally managed CA and installed client cert, but at least as safe as the web browsing you'll be doing on it after connecting anyway. The safety advantage to WPA-Enterprise over WPA-PSK is mainly due to the fact that you don't have to distribute the same easily-cloned PSK to every client. In addition, if installing and validating client certificates (not the usual mode for EAP-TTLS) they can be locked to specific user accounts. For keeping out the riff-raff they can be locked to MAC addresses as well but that only serves to ban the amateurs.
Someone had to do it.
You think that's bad? Wait until you run across the issue where your ISP doesn't even both to set up basic passwords on your wireless hub.
Om, nomnomnom...
MAC filtering does nothing useful. You're shouting your MAC from the rooftops any time you're connected to the network, so cloning it is exercise in triviality for any attacker with an IQ greater than their hat size.
upon the advice of my lawyer, i have no sig at this time
Just when you thought you've sharpened your spear to the finest, your opponent has fortified his shield to the fullest.
If you are even the slightest bit concerned with the security of data on your network, isolate wireless completely from your secure data. In my very unscientific estimate it seems 90%+ of the usefulness of wireless is for just basic internet access for executive types anyhow who don't need to be checking production data.
Just use a one time pad. It's perfectly secure, even to quantum cryptography as long as the source is truly random. Creating a truly random number generator that takes advantage of quantum effects is not terribly difficult. Many modern CPUs now have this support built-in. The only weak point is how you get the one time pad to both locations and that it can only be used once. Even this is possible by having multiple pads sent via different methods and XORing them together at the destination. In order to crack it all copies would have to be intercepted and copied though additional security measures could be added to make even this difficult.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
Ooops. I'm going to have to get a smaller hat.
http://www.rootstrikers.org/
You insensitive clod! You just blabbed my password. Now I'll have to change it to capacitor mule wrong nail.
Oh wait ...
Because SSL on Open WiFi is fool proof....
He was correct. While you are also correct, you failed to see the attack vector. If the network is not secure, your SSL may not be effective, at least not for all users.
I understand this is about recovering the PSK. This would mean that authentication using a certificate, such as EAP-TTLS is still safe. Correct?
I would say in practice "enterprise" password authentication via TLS (PEAP-* and TTLS-*) is the least secure authentication method for the simple reason virtually no client is configured properly to validate both certificate and identity.
The end result TLS is effectively subject to MITM attack for the overwhelming majority of clients...leaving squishy inner PEAP/TTLS authentication protocol (all completely worthless)
In my view EAP-TLS with mutual certificate authentication is still the most secure authentication option available.
Stanford's SRP protocol would be awesome to protect WPA passwords I believe it could be implemented with minimal changes to existing TLS stacks ... simply do TLS-SRP via EAP-TLS EAP method instead of the cert auth ... you get secure password authentication without the offline attack vector, or having to implement a new EAP method from scratch.
You mean that clients do not check proper certificate signature by the CA?
The main problem is not so much CA validation but lack of a global namespace.
When I type https://www.securesite.com/ into my browser the only certificates my browser accepts are the ones explicitly for www.securesite.com... certs for www.someothersite.com don't work.
With EAP authentication no such check is done automatically by default. To be secure the client must explicitly select a CA **AND** certificate identity (e.g. www.securesite.com) ... otherwise you might well be presented with a valid certificate.... yet you won't know if it is one legitimately assigned to an attacker. Attackers after all can buy SSL certs the same as you or I.
In too many cases the extra work is simply asking too much of the user... some mobile clients are not even able to provide necessary configuration options to secure it.
One-time pad truly means one-time pad however. That means a new pad for every single transmission - that's why it becomes untenable.
On the other hand, the way network encryption works is typically this:
(1) Use asymmetric encryption once to securely deliver the remote computer the key to a symmetric algorithm.
(2) Use the symmetric key for the remainder of the communication.
It's possible that RSA is compromised, or that a G.O. has the means to cracking it via an unpublished mathematical discovery, but there are other asyms out there.
MAC filtering even lowers security. Some lazy crackers might have not changed their MAC when they are attacking and it could be easier to identify them next time. When they are spoofing MACs they use your own MACs which they see on your network. You basically (could) lose information about the attackers. And this is bad.
I can imagine a VPN server with a rack of slots for those (Probably just read-only USB mass storage interface). Give one to the VPN, one to the person going on their trip or working at home. You'd need to send out a new key every now and again, but if a key is good for a couple of months (Doable) then it becomes quite reasonable.
It's called 802.11w and introduces encryption on management frames (so de-auth attack is out), this problem is solved. It's up to vendors/developers to implement it.
SSL is designed to operate over insecure networks. That's the idea.
Nobody knows what they did, because their paper is paywalled. From afar, it looks like the a compilation of standard attack methods. The WLAN standard uses unencrypted deauthentication packets, which enables an attacker to kick anyone from the network without knowing the network's encryption key. This can be used in a denial-of-service fashion, where the attacker continously deauths everyone, so that nobody can use the network. Or it can be used once on the victim: The victim will automatically reconnect to the network, which gives the attacker an opportunity to capture the handshake which includes the key negotiation. The attacker can then use this recording to perform an offline brute force attack to find the key. If the attacker guesses the key, he's in.
Without using deauth, the attacker would just have to wait until the victim connects to the network on its own. That's not going to stop a determined attacker, i.e. one who attempts a brute force attack on WPA-PSK.
Long story short: If that's it (I don't see any hint that it's not), then a sufficiently random pre-shared-key prevents a successful attack.
TFAbstract says that WPA2 can be cracked with brute force search, and that long passwords are more secure than short ones. Looking up the home pages of these internationally renowned researchers http://www.brunel.ac.uk/bbs/pe... http://issel.ee.auth.gr/people... http://www.research.lancs.ac.u... reveals that these three claim no other security-focused publications. But perhaps I'm too quick to judge. Somebody pay the man and read their paper. Or is this the two-step get-rich-quick scheme?: - (1) Publish Paywalled Article Exposing Security Holes in Commonly-Used Security Protocol (2) Profit! (PPAESHiCUSP-P)
They're not designed for systems but for embedded devices like firewalls, VPNs, routers, NAS, etc. They're expensive and have some very nice engines in them as well, such as the gzip engine that's 100 times as fast as software implementations, hardware pattern matching (regex) engines and content addressable memory support for firewalls and anti-virus, RAID engines for NAS to do RAID 5/6 calculations in hardware, encryption and hashing instructions, not to mention built-in support for 10 and 40Gbps Ethernet with a lot of packet acceleration. The chip of course will run Linux (Debian) and applications that run directly on top of the cores without an OS underneath for bare metal performance. The single threaded performance is a fair bit lower than an X86 based system which is why there are so many cores running in parallel. There's also a lot of special support for synchronization between the cores and various atomic instructions that have been added.
While it is fully compatible with standard 64-bit MIPS there are a lot of additional instructions since MIPS allows you to do that (ARM does not allow manufacturers to add custom instructions).
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.