Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

Wireless Networking Encryption Security IT

WPA2 Wireless Security Crackable WIth "Relative Ease" 150

Posted by timothy
from the relatively-absolute dept.
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 discussion has been archived. No new comments can be posted.

WPA2 Wireless Security Crackable WIth "Relative Ease"

Comments Filter:
  • this is not news (Score:5, Interesting)

    by Anonymous Coward on Friday March 21, 2014 @09:54PM (#46548803)

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

    • by Anonymous Coward
      Interesting that you could come to the conclusion that this is obvious only six minutes after the story was posted.
      • by Anonymous Coward

        That you are ignorant of a method's widespread use and common knowledge, does not serve as legitimate cause for you to project that ignorance onto others. This "hack" has been known for some time, arguably since the creation of the protocol, since it is central to the functionality of said protocol. The only development of any note is how much easier it has become in the interim to brute-force passwords, given advancements in CPU/GPU processing power/techniques.

    • Yeah, exactly. Nothing to see here. Show it to me happening in real time with common easily obtainable equipment and maybe then you'll get my attention. But not with a lot of maybe's, perhaps, and coulds.

    • by AmiMoJo (196126) *

      The problem is that most people use crap passwords. Too short, only alphanumeric with no special characters, a combination of dictionary words or common phrases etc. A GPU and a good dictionary can crack the majority of passwords in use today.

      What we need to do is get away from passwords. WPS isn't so good but some routers support NFC for key exchange now, which seems ideal. If the attacker is within 2cm of the router already you have bigger problems.

      • A combination of dictionary words can be a strong password. [xkcd.com] This does require a large password field, but WPA 2 seems to support 64 characters so that's covered.
        A random set of dictionary words is easy to remember for a human and difficult to guess for a computer.
        We need to get away from insane password rules.
        1. A max length of below 32 characters is bullshit. Instead, set a minimum length of 16 characters and advise to use a few random words.
        2. Requiring non-alpahnumeric characters seems safe, but it move

        • by AmiMoJo (196126) *

          A combination of dictionary words can be a strong password.

          Not any more: http://arstechnica.com/securit... [arstechnica.com]

          Combinator attacks will chew through any random combination of dictionary words pretty quickly. Length is irrelevant, only the number of words matters and typically it is quite low. In the XKCD example you linked to it is just four. For once XKCD gave out shockingly bad advice.

          • "Not any more" doesn't apply. It's no more difficult to do brute-force dictionary attacks than it has been.

            However, brute-forcing a "correct horse battery staple" password (Munroe apparently was thinking of random selection from a 2K-word dictionary) does involve an average of 2^43 attempts, something over 8 trillion (best/worst case is double that). At a million tries per second, it would take well over a week. At a billion tries per second, that would take more than two hours. That's not about to s

  • Eh... (Score:5, Insightful)

    by Anonymous Coward on Friday March 21, 2014 @09:59PM (#46548815)

    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?

    • by MtViewGuy (197597)

      It could be fixed by upgrading the software used by routers and by client devices, but 1) everyone has to agree on an updated standard and 2) how are they going to do the upgrade for Android-based cellphones? (Easy to do on an Apple iOS device--just run an update to iOS itself.)

      • It undoubtedly will be fixed with adoption of an enhancement to the existing protocol or an entirely new protocol. We saw that with the evolution from WEP to WPA to WPA2. The challenges are that this will take time for a fix and new standard to be determined and the processing capability of the currently deployed wireless infrastructure. There is a fair likelihood that today's access point will not have enough horsepower to efficiently process the next generation authentication and encryption protocol.
        • by MtViewGuy (197597)

          That's what I said about Number 1--everyone has to agree on a new variant of the WPA standard. That could take a while. Meanwhile, I use a 16 alphanumeric character randomized password that will be still very hard to crack by brute force.

      • Call it WPA 3 (or WPA 2.5 if you don't feel the change warrants a major number change) and treat it like any other system.
        If not all of your devices support WPA 3 you set the router to WPA 2 and "hope" nobody hacks you (not really hoping. It isn't an issue in most home applications).

  • by fustakrakich (1673220) on Friday March 21, 2014 @09:59PM (#46548817) Journal

    How do you keep something you never had?

  • I already have to tell friends and family to use a alphanumeric password not based on a dictionary word - I was helping a friend find out why her wireless charges were so high, and using backtrack and some basic documentation - (knowing almost nothing about wireless security) - I was able to find out her wireless password based on the fact she was using a regular word in my dictionary list

    wireless = never safe

    • by Mashiki (184564)

      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. [dslreports.com]

    • by Anonymous Coward

      A moderate-length (24+ chars) phrase will be way more secure than your random pattern of letters, numbers and characters, PLUS it's FAR easier to remember, thereby reducing the odds that the super-secure gobbledy-gook you forced them to invent wont just get written down on a piece of paper and stuck to the refrigerator door for every passer-by to read...

      Oblig XKCD [xkcd.com]


      • by Anonymous Coward

        For a system where finding a written-down password is as difficult or easy for an attacker as getting physical access to the network, creating a long truly random password and writing it down really isn't such a bad idea. On the other hand, a phrase which is comprised of dictionary words, chosen by a human and "moderate length" according to your definition does not have enough entropy. Researchers found human-chosen four-word passphrases to have only about 20 bits of entropy. That's far less than a truly ra

  • I understand this is about recovering the PSK. This would mean that authentication using a certificate, such as EAP-TTLS is still safe. Correct?
    • Re:EAP? (Score:5, Interesting)

      by skids (119237) on Friday March 21, 2014 @10:32PM (#46548925) Homepage

      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.

    • Re:EAP? (Score:5, Interesting)

      by WaffleMonster (969671) on Saturday March 22, 2014 @12:47AM (#46549361)

      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.

      • by manu0601 (2221348)

        You mean that clients do not check proper certificate signature by the CA?

        • 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/ [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 certificat

          • by manu0601 (2221348)

            Attackers after all can buy SSL certs the same as you or I.

            But AFAIK, there is no preloaded CA for EAP. You install only the CA of your organization, which narrows the opportunities to have a valid certificate.

            But indeed if someone steals any certificate you signed with the installed CA, an attack is possible. That advocates for using a sub-CA, or a dedicated CA just for EAP.

            • by Xylantiel (177496)

              I believe the problem is that the interface for this and the way warnings are handled is just horrible and inconsistent between clients.

              For example, android requires yout to set a passcode in order to store the public certificate. That's right you need to lock your device so nobody can get access to that PUBLIC key. duh. Clearly you should have a passcode for a private key, but not a public one. I"m not sure if this has been straitened out or not. Also it's often not clear if you can say the equival

            • by skids (119237)

              But AFAIK, there is no preloaded CA for EAP. You install only the CA of your organization, which narrows the opportunities to have a valid certificate.

              Depends on your security requirements. Most OSes trust anything in the OS default trsuted CAs which includes most major CAs. If you're satisfied with the integrity of all the CAs in that list, you can buy a RADIUS server-side cert form them and the clients will trust it.

              The problem comes in making sure the self-service user checks the box to perform the validation and also types in the expected owner name. By default most OSes do not validate this information so anyone with a stolen priate key from a CA-

              • by manu0601 (2221348)
                If one device has commercial CA configured, and it does not check the CN, this means that any certificate obtained from a valid CA can be used to highjack EAP. It looks like a rather severe vulnerability.
      • Importantly, this is also where we get into that root cert problem for companies that people complained about in a recent /. story because a lot of companies just use their own internal CA to authenticate the certs for both users and wireless devices which requires installing their root CAs on the machines and trusting them.

      • by skids (119237)

        In my view EAP-TLS with mutual certificate authentication is still the most secure authentication option available.

        You;re half right, but EAP-TLS doesn't have a password/account component, just the cert, so you are missing an authentication factor. If you're going through the trouble of actually making sure clients are running a secure supplicant to the point of making users add a client cert and a local CA trustpoint, just secure the settings on the TTLS/PEAP client and ban OSes like android that don't validate. Turn on verification of the client-side cert if you like, too.

        • You;re half right, but EAP-TLS doesn't have a password/account component, just the cert, so you are missing an authentication factor.

          Clients can ask user to provide a password to access/decrypt private key required to authenticate client to server. The "account" component is client identity (e.g. name of public key)

          If you're going through the trouble of actually making sure clients are running a secure supplicant to the point of making users add a client cert and a local CA trustpoint

          I've been pushing vendors for 10+ years for a usable solution and they don't seem to care.

          All most people want is passwords without all the worry about brute force attacks. Users and Operators alike don't want to deal with certs at all ..there is no *good* reason they should have to.

  • so? (Score:4, Insightful)

    by the_Bionic_lemming (446569) on Friday March 21, 2014 @10:22PM (#46548889)

    Brute force attacks compromise simple passwords?

    This is news?

  • by msobkow (48369) on Friday March 21, 2014 @10:27PM (#46548907) Homepage Journal

    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.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      Uh, you're forgetting that a wifi connection is two way. If they can get onto your network, they're inside your hardware firewall. Better hope you have a good software firewall and/or that you don't have any exploitable services.

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

  • What has limited the attack number in WPA-PSK? That's the question I have after reading all the data that is freely available. From what I know and can gather about this, the researchers found a way to reduce the amount of brute forcing required to guess the key in WPA-PSK. They used something in the de-auth and probably re-auth after that to gather information about the key to do so.

    Paywalling this information is a bad thing. Either do a full disclosure, or keep it secret and notify all vendors that are
    • Re: (Score:2, Informative)

      by Anonymous Coward

      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

  • by Anonymous Coward

    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.

  • by jon3k (691256)
    This article is a really takes a really roundabout way to tell you computers are getting faster...
  • by craighansen (744648) on Saturday March 22, 2014 @10:55AM (#46551557)

    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... [brunel.ac.uk] http://issel.ee.auth.gr/people... [ee.auth.gr] http://www.research.lancs.ac.u... [lancs.ac.uk] 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)

Put your best foot forward. Or just call in and say you're sick.