"Brute Force Attack will take up to 128299838271 years" at 500,000 passwords a second. ElcomSoft is claiming a 20x improvement in speed, but that won't make a dent into an exponential-sized problem.
See http://lastbit.com/pswcalc.asp [lastbit.com] for calculation.

I personally recommend KeePass for password generation. It can generate 63 char passwords for WPA/WPA2 keys with cryptographically random unpredictability as it uses keyboard/mouse movements as part of seeding. Because its done on the local machine, there is no chance of the password being leaked as compared over the web. With a 63 character password, that is far more entropy than the 128 or 256 bits keys used for AES, so for someone to guess a password of that length, they either have to be able to brute force AES at full strength, or find a weakness in the algorithm's implementation.

I generate a KeePass password, save it to a USB flash drive, then paste it into my router's config. I then take the USB flash drive to the physical machines and do a copy and paste of the 63 char key into their network preferences. This is a lot easier than typing it. Should I lose the key... not hard to fix -- generate another one and rekey the 3-4 machines on my network. Because the WPA/WPA2 key is easily resettable with physical access to the machines, there is no reason to go less than the maximum character length, and it doesn't matter if the password gets forgotten, as long as you remember your router and machine's access passwords. (This for a home network. Businesses should use a RADIUS server where all the machines are not reliant on a single shared encryption key.)

If you have to use fewer characters, I'd say never use fewer than 20 characters, but even that is cutting it thin, factoring in Moor's law, botnets, and usage of GPUs for additional number crunching.

I'll second KeePass and its UNIXy-OSXy variant KeepassX (the DB file that it stores passwords in can be read on all three platforms). In addition to its password generating abilities, it makes a handy home for my network/web logins. Sourceforge has both programs in all their gleaming, open source goodness.

Yeah, that's great.... But it doesn't work too well for the "I'll set up our 200 unit network for wireless in 2 hours" crowd. Those are the ones who are likely using WPA with PSK and easy-to-type-in passwords.

This is either utter ignorance, or a mediocre troll (in the nicest way, of course).

Firstly, get rid of this idea of a "standard password". Get PasswordHasher [mozilla.org] and use your NEW standard password to access some highly complex passwords at no extra brain power.

Next, your next door neighbour can't plug into your router from their sofa if you use a cable and see you moving home pr0n between your laptop and your desktop.
If you're using WiFi then all that lovely data could be shared with them, if they have a sniffer program running and your network key.

Other things that go over your network in plain text that could be sniffed by your neighbour: Notice the httpS:// on Slashdot.org? Me neither. Your password would have been in a packet that they sniffed. Same for any site you visit. URLs to your bank, your fave pr0n sites, the software you're using and which versions. If they are as good as me (and I'm not even that good at this crap), they could wait for your browser to look for an update, have an already altered version of the last update with a backdoor in it, hijack the DNS request and punt you a file that rootkits your box. If your post wasn't a troll, you might need this: Rootkit [wikipedia.org].

Seriously, why do you think everyone talks about wireless security as if it was important? Are you the only one that is "in the know" and they are all wrong?

Exceptions do apply. NX, VPNs, SSH, and other encryption can be sent over totally open WiFi because the encryption is done before stuff hits the network card.

Your example password is not random. Look at the letters of it, one by one, and you will notice that each next letter is either in direct physical proximity (QWERTY-wise) to its predecessor, or in a similar proximity for the other hand. This is a serious weakness because password crackers will exploit it in an instant.

That's a good reason not to used closed source software or a web page. It's not a good reason not to use Keepass, the program suggested above, which is open source, offline, and has high-entropy random number generation. Saying some software is bad so I won't use any is like saying some clothes are bad so I won't wear any.

Randomly banging on the keyboard clearly produces less than ideal entropy. Case in point, your password contains "asedf", which I'm willing to bet was the result of you drumming the fingers of your left hand. Now, whether it matters for such a long password is another matter, but if you're paranoid enough to use a password like that, you may as well go the extra mile.

You would trust some random other person's web site to generate a critical password? I admit it's probably better than what many people do, but it's almost certainly not acceptable in a commercial situation.

Other's have already provided some downloadable solutions, but here's a solution which should be available on most modern operating systems. Just get to a command line and type the following.

So let me get this straight: you're recommending I set my password to what some dude on the Internet is telling me to, and who can trivially connect it to me since he knows the IP address it was sent to ? And the dude, who's presumably advocating this practice since he's going out of his way to enable it, is supposedly a security expert ?

I was a little worried until I also read it was nothing more than a brute force attack using a faster processing unit.

My thoughts exactly. This is like fitting two bigass turbochargers and jumbo cams to a big 'ol American V8 and calling it a breakthrough in engine design. The headline should be "Elcomsoft turns WPA/WPA2 brute force attack speed up to 11"

Heh, my old password would have taken 1,559,007,293,804,841,500,000,000 years (20 chars, uppercase/lowercase/digits/common punctuation) to crack at 500,000 combinations/second. I recently moved up 23 chars, but it won't calculate that for me.

Although while 500,000 combinations/second may sound impressive, it is a useless metric without comparing it to how many combos/second a normal machine can pump out.

"Brute Force Attack will take up to 128299838271 years" at 500,000 passwords a second. ElcomSoft is claiming a 20x improvement in speed, but that won't make a dent into an exponential-sized problem.
See http://lastbit.com/pswcalc.asp [lastbit.com] for calculation.

Yep. And computers won't get any faster in the next 128 billion years...

So, computing speed doubles roughly every 18 months. At this rate, it will be down to one year in 55 years (assuming computers keep getting faster at the same rate - 55 years is about as long as we've had commercial computers).

Of course, if you add another alphanumeric to the password, you multiply the complexity by 56, which adds another 10 years to the time before computers will be fast enough to crack it in a year. Another alphanumeric takes it up to 73 years, another up to 81, and so on.

There are some physical limits [wikipedia.org] to the maximum speed of computation. All of the ones we've come close to so far have been practical engineering problems, rather than theoretical ones. 21 more doublings in transistor density and IC features are smaller than the nucleus of an atom (9 more and they're smaller than a helium atom including its electron cloud) - only possible if you're building your CPU out of neutronium, so it seems unlikely that we'll get to 54 without some brand new physics. Increasing transistor density isn't the only way of increasing computational power, but so far it's been the easiest (although each doubling does require an R&D budget measured in billions of dollars).

So, all I need to do is record the data, crack the first set of keys and then I can decrypt all subsequently sent packets as you have convieniently provided the new keys in the (now decrypted) data stream.

He's pushing out the new key over the network using the existing key. I record all data over the network starting with key XX1. Say he gets to key XX3 when I finally crack key XX1. I use key XX1 to decrypt all the data I have recorded from the wireless, I get key XX2 by decrypting it and then I also get key XX3.

But with modern wireless technologies, how much data can you really push in 12 hours? Let's say you're on a -g network -- 54 mbits -- you'll probably send at most 5 megabytes per second. Suppose you're saturating that constantly -- that means roughly 18 gigs an hour.

So, it takes me 12 hours to crack that -- which means I have to record at most 216 gigs worth of (encrypted) data.

At the end of 12 hours, I've cracked the key from hour 1. I can then go back and decrypt all traffic you sent during that time, including the key you set for hour 2. Then I can decrypt all the data from hour 2, and so on. This will probably take less than an hour.

So, in other words, your rotating key scheme only works against people who either aren't recording your data, or aren't interested in cracking it at all (for instance, it'd be great if you give a houseguest access for an hour, then the next hour, the key changes from under them)...

When you first initiate the connection, you ask the wireless network for the current salt, SALT in plaintext.

You then use a very secure hash (I think that the one that I wrote a while ago is probably secure enough, though this is an unwarranted assumption, as I haven't shown it to any security experts) and take the hash of SECRET salted with SALT. You use the hash value as the key.

[This is where someone else who knows something about crypto chimes in... I just know this because I'd seen someone else getting called out on this misconception.]

W007! I actually do know something about crypto (as well as number theory, which is useful and fun).

You are right about the fact that, if SALT were transmitted through plaintext every time, it would only be a matter of time before SECRET would be able to be deduced (assuming that the method of breaking the overall WPA encryption allows you to figure out the encryption key being used [I don't know too much about WPA in particular, so I'm not sure if it is public key or not]).

I should have been clearer. Every XX minutes, a different SALT is transmitted via ciphertext.

This increases the complexity of the problem significantly:

You must break the first encryption key and gain the full key. The key looks something like:a8fbcd1db5a6bf013763fd45a32f2b319bfba413

You must break the second encryption key. Again, the key looks something like:216cd69e6e4112b6adffec1853ae415b0fa45fcf

[Wash, rinse, repeat]

You eventually have enough keys lined up to figure out that they use the sha1sum and all start with "this is insanity ", therefore SECRET="this is insanity ".

The problem is that you have to break the encryption scheme enough times to gain enough keys to establish what SECRET is. Then you have to break the hash. If it is a particularly good hash (i.e. NOT MD5 OR SHA1!) and the key that you are hashing has sufficient entropy (i.e. consists of random data) then you shouldn't be able to break the hash using a rainbow table, and brute force might be necessary.

Now, you can always try to mathematically find a flaw in the hash or encryption scheme, but that is a different problem. Personally, I wouldn't trust an encryption scheme designed by someone else unless I had the mathematical background to prove it, which, in the case of RSA, I do. Therefore, I would use RSA with as large a key and block size as is feasible. I'd probably also write my own implementation [activestate.com].

(I must confess, though, that the implementation I wrote to which I have linked is not by any means secure as it stands. It is also probably buggy, as I spent maybe half an hour on it at most. Someone commented on another recipe that writing RSA should be simple, and so I took the opportunity to write it.)

That was my reaction, the standard advice going back a long ways was use WEP, but for the love of god also use VPN between the devices. I can't imagine why WPA or WPA2 would make people think that you should be ditching the VPN.

Admittedly I've been guilty of not doing it, but it was more a matter of inferior Windows facilities than anything else.

That was my reaction, the standard advice going back a long ways was use WEP, but for the love of god also use VPN between the devices. I can't imagine why WPA or WPA2 would make people think that you should be ditching the VPN.

Since WPA2 uses the same encryption that you'd find in a VPN, I wonder why you think it would be less secure?

Rotating keys is not a smart way to try to extend the keyspace, if he can brute force one password he can quite probably do it again. Rotating passwords is a good idea if unwanted people may have had access to the password or a device it was on like say in a corporate network, guest network or whatever. For the traditional home network where the overwhelmingly likely scenario is that he's got no inside knowledge, just set one password at maximum length with some special characters so you're using the full k

Rotating the keys doesn't help that much to close the window for attacks.

Cracking a key is a matter of chance. At a certain rate of checking trial keys, you'll have a certain chance in an hour of cracking it (except that admittedly the chance does go up with time with a fixed key as you exhaust possibilities).

As long as the attacker is constantly attacking the currently active key, then it's not much harder to break a changing key than a fixed one. Though with a fixed one, there is an upper bound (once the

Which is a meaningless statement, because it's not a choice between one strong key versus ten lesser keys.

There's nothing stopping anyone from using ten strong keys.

In theory that's true, in practise try keeping a family network with say 3-4 laptops going with rotating keys like "aDgWTgGS&)=DG&%T4/3fDH5d532NF3" and see how long it lasts before you're cursed at and asked to turn that damn thing OFF! Because you are talking about typing in that manually each time it changes, not broadcasting a new key on the wireless which the WPA standard already does, right?

Most businesses I've seen have had easily guessable passwords, used open relays, or WEP encryption. Many don't change their keys even after firing someone. Saying that this is a "death knell" is serious hyperbole since, for many companies, convenience trumps hardened security.

That said, the biggest risk is still always going to be insiders and former insiders who won't need to crack into the wireless network: they will already know how to get access.

In terms of quantity of seperate attacks, partner networks and outsiders are the biggest risk. In terms of records stolen per breach (still arguably not the biggest risk, since Verizon didn't report cost/record) insiders were top.

For instance: The company where I'm working has operated for years on the assumption that WiFi's own encryption is just a warning sign and trivially broken.

They have the WiFi on its own subnet with its own firewall. Get on (with the WEP key) and you can only reach the nameserver, VPN server, and SSH server. Use an encrypted tunnel or you might as well be standalone.

A "100x" increase in the speed of cracking an encryption system is not necessarily impressive, or indeed meaningful.

It sounds like a lot, and would be if it were a situation of "It used to take 100 years to crack a password, now it takes 1." Ok well that just moved the problem from something impossible or at least totally worthless (the technology will be outdated by the time you get the answer) to something potentially useful for a determined attacker.

However, that isn't the sort of timescale we are talking about for modern encryption. We are instead talking about amounts of years that are generally expressed with exponents. Ahh, well now that changes things. If an encryption system currently takes 10^14 years to crack and you've sped up cracking 100 times so it now only takes 10^12... Well that still doesn't get you anything. You are talking many times longer than the universe has been around. Even an increase of 1,000,000 times doesn't get you anywhere near anything useful.

So while announcements like this are cool in an academic sense, they have no real application or threat.

Seriously. We've had a number of standards with names like "Wired Equivalency Protocol" and "Wifi Protected Access" and yet they seem to be falling, one-by-one, to relatively trivial attacks. I'm not saying that WPA is as bad as WEP, but how come they can't copy/paste something as good as good old-fashioned SSL?

SSL has withstood the tests of time, over, and over, and over, and over again. SSL is the gold standard for encryption. It's used on every HTTPS website, it's used for SSH, it's used as part of kerberos, IMAPS, POPS, TLS, and just about every other good-quality security tool.

So why are wireless chipset manufacturers trying to re-invent the wheel, when it's widely known that these kinds of wheels are FRIGGEN HARD to re-invent well?

Start with normal, unencrypted wireless. Getting that to work was solved long ago. Embed an SSL engine into your wireless device, with a randomly generated private key. Provide a means to access the public key, and copy/paste that key into your high security wireless driver. If you want to be paranoid, your local driver generates a private/public key pair as well, and that can be copy/pasted to your wireless device.

Done! Now you *KNOW* that if you are accessing the Internet through the driver, you are doing so through the correct wireless hotspot. Who cares about wireless MITM attacks at that point? The SSL protocol *ASSUMES* that there are MITM attempts, and foils them quite effectively, over the equally open and unsecured Internet.

Seriously, folks. This is a problem that was solved over a decade ago. Why are we doing this again?

Seriously. We've had a number of standards with names like "Wired Equivalency Protocol" and "Wifi Protected Access" and yet they seem to be falling, one-by-one, to relatively trivial attacks.

"Seem" is the key word in this paragraph.

The claimed attack is nothing more than a brute force search on WPA/WPA2 pre-shared keys, a search that will fail if the keys are well-chosen. It has no effect whatsoever on WPA or WPA2 when used with any of the EAP authentication modes. But PSK requires the network admin to choose a key, and the key is typically chosen by typing in a passphrase. If that passphrase is weak, then given enough computation power an attacker can guess it. Big surprise.

WPA and WPA2 ARE just as solid as SSL. The only difference is that everyone knows that if you're doing SSL you should use a good random number generator to help generate your key pair and to generate the session keys.

I used this. Not so for the security (I think a 63 character really random password would be enough), but for convenience - it was easier to copy two files (user certificate and CA certificate) to my cell phone than type ten 63 char password (which for some reason was reset after each phone reboot)...

Now I do not use wifi for my local network. For some reason the AP usually failed to authenticate users, so I scrapped the idea and now use the same AP as a client to my ISPs wifi network. It works now...

So this means that though I'm using the longest key my router allows, because I only used a decent pseudorandom generator instead of a true random generator, I'm toast. Oh, Noooooooooo!

Incidentally, I've usually powered my wireless router off when I'm not going to be using it. But then at some point I realized that cracking requires snooping on a successful connection. If there's no successful connection, about all they can get is my SSID.

The reality is that most businesses and home users don't want to deploy a Certificate Authority to make use of SSL. WEP, WPA, and WPA2 are "cheap" encryption solutions. If you are really worried about it, there are existing cert based solutions available that are independent of the wifi router/access point.

You don't need a certificate authority to use SSL. SSH works fine without a Certificate Authority. The only value that a Certificate Authority provides is in positively identifying/validating a participant that you didn't previously validate.

The protocol I mentioned requires no certificate, since the public key is being copy/pasted with a mechanism that is otherwise trusted.

The TLS standard (effectively SSL 4) mandates that the server present a certificate for perusal by the client. Sure, you can use a self-signed certificate, but then you're not using TLS in a secure fashion.

SSH and Kerberos are not based on SSL/TLS. SSH probably uses similar techniques to SSL, but Kerberos is out there doing it's own wacky thing. See here [mit.edu] for an explanation of Kerberos's operation.

Well, SSL is one option, sure. Sun's SK/IP system would be another, since it was designed with unreliable connections in mind. Requiring client-side certs and using any of the public-key systems (ECC, for example) would be vastly superior to a shared key system. If privacy is not as big of a concern as just authenticating who sent the packets, 802.1x offers some interesting possibilities. Of these, how many are implemented in low-cost COTS wireless devices? 802.1x appears in a few, but not many. The others

1) SSL as it stands for HTTPS and what not typically uses key lengths anywhere from 128-bit all the way up to 4096-bit.2) WEP/WPA requires the router to decrypt all packets over the wireless network so it can route them.3) Longer keys = More Processing power required.4) Encrypting and Decrypting everything may involve a performance hit without more processing power.

End Result: You want it more secure, the router is gonna need more RAM and CPU power to pull it off which means instead of picking up

I am the Minister of the Nigerian Ministry of Butt-loads Of Networked Nvidia PCs (NMBNNP). We would like to test this software, but in order to determine if the software has successfully cracked the password, we need your login password, so that we can verify.

Proof that the best solution, by far, is to use wires. Wireless is fine when you don't care what's being sent over them (browsing, etc), but for any serious business or otherwise sensitive information, I want to be plugged into an actual, physical network. Not that it's 100% secure, of course, but at least your information isn't flying around in the air waiting for someone to decrypt it, and given time, *anything* can be decrypted.

This anouncement effectively signals the death of wireless networking in business networks;

Bullshit. The underlying encryption is based on AES*. AES is not a toy algorithm, and is designed to defend against specialized cracking hardware, and all other known attacks. It is *plenty* strong enough to hold up to a 100X increase in cracking speed, as long as you use good keys, which hopefully you are in a business environment.

I'm willing to believe that a key handling vulnerability might exist in WPA, or a flaw in AES, but the notion that brute force has brought about the death of WPA in business networks is just absurd. At best, this is a reminder to use good keys.

any network handling sensitive data should start using VPN encryption on machines connecting over Wi-Fi networks, or stop using these networks altogether.

Do you think your VPN software has a better underlying algorithm than AES?

* Unless you're using TKIP, which is a toy algorithm, which exists for backwards hardware compatibility, and in my experience isn't used by anyone who cares about security... But even there, the potential attack vectors are through algorithm weaknesses, not brute forcing the keys.

When used with any authentication scheme that is *not* PSK-based, WPA is still pretty secure. VPN connections are perfectly fine as well, as long as you don't choose a simple guessable pre-shared key...

Also, any real business (even my university) is using WPA2-Enterprise, which is AES / 802.1X based. There are not pre-shared passwords that suffer from possibly being too short, and each client negotiates the actual encryption per connection, and there's re-keying so even if you could crack the encryption for one client at one time, you still would have to repeat the task for every other client and other sessions.

WPA-TKIP was built as a "transitional" standard. It is good enough for today, but we expect that to not last for very long.

WEP=breakable by your grandma.WPA-TKIP = very little security margin, was designed for a 5 year "transitional" period to move to AES. Not recommended for long term or high security use.WPA2-AES = strong.

The article says that 3DES has been broken. I think they are mistaken. DES was cracked by a brute force attack but 3DES is still considered secure.

How is their distributed processor system going to crack a 128-bit key that has 128 bits of entropy? Maybe the solution is to update the wi-fi software to make it easier to generate, transport, and install, truly random keys.

Weird that this article seems to call down doom for WPA in general and particularly in the enterprise.

a) 100x increase, even using 10,000 machines seems insignificant if you are using the maximum WPA key length employing uppercase, lowercase and punctuation? Even a 30 char password seems to last far longer than most of us will be alive. So at worst all this changes is the minimum key length that can usefully be employed on WPA.

b) In the enterprise in my experience you either use no encrypting and rely on

You're forgetting how many zombie computers there are in existence that can be used at a hacker's whim to crack such... But that aside being able to use processing power on other things like PS3's and what not could help speed things up particularly if you can make their GPU's do what you want as well.

Using GPUs to crack is not "new", it's a well known tachnique. Furthermore, an increase of a factor a 100 is insignificant relative to the number of years it would take to crack a key, hence the crypto is not weakened, dispelling their whole "death of wireless networking" doommonger bullshit. The only thing this actually does is speed up already feasible attacks against bad passphrases, nothing new, and certainly not a "breakthrough".

wpa2 with a shared key is only crackable with a brute force attack. Assuming that an alphanumeric character is used for each character of the attack, then for a key of length 8 (the minimum) the attack takes 26+26+10+10=72^8 (lowercase+uppercase+numbers+shifted num keys) time which is 7x10^14. A factor of 100 isn't a big deal - it reduces it to 7x10^12.

Even worse, if the key is longer than the minimum, say 14 digits, then the number of brute force keys are 1x10^26 and improving that to 1x10^24 isn't going to make much of a difference at all.

The WIFI at my workplace is available, there is little if any security and the traffic isn't encrypted; why? well it has always been associated with being insecure, so when WIFI was rolled out it was placed on the Big I instead of the little i and to get anywhere internal you must bring up a VPN tunnel to work, add some poisoned routing information on both sides to account for the networks being used (internal versus internal) and you have some hope of preventing someone from bridging i to I.

You shouldn't use WIFI for anything that you wouldn't want to share openly and even if you believe that what you are doing is secure you should know that someone could still be capturing your session and working on it offline; the vendors haven't helped either, most wireless routers will 'work' right out of the box, purchase at worst-buy, plug it into your cable modem and in 60 seconds your on, I can't tell you how many networks I've found this way, most still have the default admin account set (just google the model number being advertised by the network)and your in....

Their approach seems to be doing nothing but speeding up brute-force searching for the key. If it's a "bad" key, like a simple word, this will speed up the search greatly. If it's a "good" key then speeding up the search 100 times is, for all practical purposes, meaningless. Get back to me when you've achieved a 100 * 100 * 100 * 100 * 100 * 100 *100 * 100 faster search.

The flesh of the wireless user, that is. Or their brains.
With the "personal" version of WPA or WPA2, the user enters a password or a passphrase, and the key is essentially a sophisticated hash of the password. As many have already pointed out, the article basically describes "automated password guessing". This is basically the same tool that we used in the old days to "recover" passwords from the hashes in the password file. Try a password, check if the hash match. Repeat with many plausible passwords. Wi