I currently have a network set up with WPA2 and AES encryption, the password is 8 characters long but was randomly generated and contains no dictionary words. However I'm concerned about the increasing power of computers and their ability to crack handshakes, as such I was considering increasing the length.

I'm aware that I can go up to 63 characters if I were extremely paranoid, but unfortunately I have to type this password into Android phones and other devices so I'd rather keep it reasonably short to allow for it to be easily typed.

Would a 16-character random password be enough to secure a WPA2 encrypted network? What is the current recommendation for password lengths, especially for wireless networks and what password length would be sufficient to protect my network against a standard attack?

6 Answers 6


Yes, 16 characters is more than sufficient, if they are randomly generated using a cryptographic-strength PRNG. If you use lower-case, upper-case, and digits, and if you generate it truly randomly, then a 16-character password has 95 bits of entropy. That is more than sufficient. Actually, 12 characters is sufficient; that gives you 71 bits of entropy, which is also more than sufficient for security against all of the attacks that attackers might try to attack your password.

Once your password is 12 characters or longer, the password is extremely unlikely to be the weakest link in your system. Therefore, there's not much point choosing a longer password. I see people who recommend using a 60-character password, but I don't think there's any rational basis for doing so. My view is that usability is very important: if you make the security mechanism too hard to use, people will get annoyed and may be more reluctant to use it in the future, which isn't good. A secure mechanism that isn't used isn't doing anyone any good. That's why I prefer to choose a shorter password, like 12 characters or 16 characters in length, as it is perfectly adequate and more usable than a monstrous 60-character beast.

Be careful how you choose the password. You need to use a cryptographically-strong PRNG, like /dev/urandom. For instance, here is a simple script I use on Linux:

# Make a 72-bit password (12 characters, 6 bits per char)
dd if=/dev/urandom count=1 2>/dev/null | base64 | head -1 | cut -c4-15

Don't try to choose passwords yourself. Human-chosen passwords are typically easier to guess than a truly random password.

One very important caveat: There are other issues as well, beyond password length. It is very important that you turn off WPS, as WPS has major security holes. Also, I recommend that you use WPA2; avoid WPA-TKIP, and never use WEP.

  • 3
    Thank you for your advice, I plan on using KeePass to generate the password which should be secure for generation as far as I know. It's also quite handy as I can specify rules to keep it to ASCII leaving and keeping it at around 16 characters. The one problem I face is that it needs to be shared among family members, to be honest I could just print it out and stick it to the back of the router. At that point you'll have access to my house and the router so I have much worse problems. Luckily for me I'm using DD-WRT which doesn't even support WPS, so I'm in the clear there. Commented Jun 6, 2012 at 19:06
  • 1
    Is the 71 bits of entropy recommendation still relevant in 2020?
    – ps_ttf
    Commented Jul 17, 2020 at 10:48

This question has been asked many times before, a 12 character password that has numbers,signs, lower and upper case letters will take a very long time to bruteforce. If your password is not present in a dictionary, then you will need to use a bruteforce attack. We can do an estimation on the amount of passwords tried:

If you have 94 possible characters (ASCII) and your password is 12 characters long. Then you will have:

94^12 = 475 920 314 814 253 376 475 136 possibilities

With a modern GPU (I found this on Tom's Hardware):Toms Hardware

You can get around 215 000 guesses per second. So if we look up how long it will take:

475920314814253376475136/215000/3600/24/365/1000= 70190000

Millenia to guess your password (actually half that amount statistically).

  • 3
    calling wpa2 an encryption function bothers me deeply. Also the PSK 4-way handshake doesn't even use encryption because it hasn't established the encryption key. The handshake is PBKDF2-HMAC-SHA1. I have no idea how you where able to calculate the years without knowing the function -1 for clear misinformation.
    – rook
    Commented Jun 5, 2012 at 13:40
  • I missed there, I meant AES. I just guessed around 200k guesses per second, and I looked some things up and came to this number. Commented Jun 5, 2012 at 13:41
  • 1
    Yeah AES doesn't come into play when cracking WPA-PSK. The -1 stays.
    – rook
    Commented Jun 5, 2012 at 13:41
  • 2
    What Rook isn't explaining is that AES in CCMP mode is used in WPA2 for encrypting data. When talking about attacking the key, though, one usually brute-forces the password that generates the key. For that, the timing is instead a question of PBKDF2 iterations rather than AES key testing.
    – Jeff Ferland
    Commented Jun 5, 2012 at 13:55
  • So my current edit would be correct then? Commented Jun 5, 2012 at 14:06

I wrote up a little script in Perl for you at the bottom. You should be able to interpret it and get your answer with a calculator as well, though.

Remember that if your password is in a dictionary or short enough to produce Rainbow tables for that the effective strength is much weaker that would otherwise be calculated. Benchmark PBKDF2 to determine how fast a password can be tested (Lucas points out 215,000 with some heavy graphics hardware). Note that Rainbow tables will be a factor if you have a common SSID name ("linksys"), but won't be if you have something much more obscure.

#Number of possible ASCII characters.
#All lowercase letters is 26, upper and lower case is 52, numbers adds 10, etc.
#Assume equal weighting and distribution.

$charRange = 0;
$length = 0;

$entropy = log($charRange)/log(2);

#Operations per second -- how fast a password can be tested
#using the given algorithm

$opspersec = 0;

$strength = $entropy * $length / $opspersec / 2;

print "On average, it will take $strength seconds to crack your password."
  • Thanks for your advice, I would vote you up but unfortunately I'm not at the point where I have enough reputation. I appreciate the fact that you took the time to write a Perl script however I unfortunately don't have powerful hardware myself so I'm going on others estimates of how fast a WPA2 AES handshake can be cracked. Still I'm sure it will be useful, although I personally do use a calculator most of the time. I was just quite unsure of what can realistically be cracked with modern hardware especially as I lack any powerful GPU's myself. Commented Jun 6, 2012 at 19:12
  • @Pierre I'd just consider Lucas' 215,000/sec to be useful for calculating
    – Jeff Ferland
    Commented Jun 6, 2012 at 19:30

There's really no one-size-fits-all answer for this. The short of it comes down to this: If you want a proper balance of security and usability that's right for you, make the password as long and complex as you can tolerate.

For me personally, I have no qualms about setting a 63-character randomly-generated PSK on my access points. Yes, it may be difficult to enter into smart-devices and such. But the thing I keep reminding myself with this is that I only need to enter it one time per device. Adding new devices to my network is a relatively rare and insignificant occurrence, in comparison to the amount of time I actually use the network and the security enhancement of a nigh-unbreakable password.

If you can't live with punching in a 63-character randomly-generated password one time per device on your network, scale it down until you get to something more easily digestible for yourself. Perhaps find a sensible way to make a long, seemingly-random password that actually makes sense to you. Depending on how far you want to go to secure your network, you may also want to consider defense-in-depth additions such as MAC address filtering, network partitioning (i.e.: firewall between Wi-Fi & LAN), and VPN.

As far as general password recommendations (Wi-Fi and otherwise) go, here's my suggestion:

  • 15 character minimum.
    • Many older standards say 8, most new standards say 12, and some even recommend 20 or more.
    • I say 15 as a bare minimum, because it forces older versions of Windows to not store the insecure LANMAN hash.
  • Use all 4 character types.
    • Uppercase letters
    • Lowercase letters
    • Numbers
    • Symbols
  • Avoid including actual words, or simple variations of words, in your password.
    • "password"
    • "P@$$w0rd"
    • etc.
  • Don't write your passwords down, or store them in cleartext files.
  • Don't share your passwords, and don't reuse high-sensitivity passwords across multiple sites.
  • 1
    There's one thing I've pointed out in other replies and that's the password needs to be shared with family members. I know the rule is to never write the password down, but I came up with the idea of sticking it on the back of the router. If someone needs to get it they can and if you manage to break into my house and get to my router you can do a lot worse things to my network and they have physical access to the one thing securing my wireless network anyway. Commented Jun 6, 2012 at 19:16
  • @ConcreteDonkey My WiFi password is never "shared" with guests to my network - I configure their computers myself.
    – Iszi
    Commented May 30, 2014 at 13:18
  • 1
    @iszi, if you put it into their computer, they can get it out of there...
    – hkBst
    Commented Jun 30, 2017 at 15:00

Obligatory xkcd reference.

What really matters is how much entropy your password contains. The problem is "entropy compared to what"? If your password is in the attacker's 100 word dictionary, then it has less than 8 bits of entropy even if it is using a wide mix of character types, e.g. Pa$$w0rd. The general rule I've heard is the English has about 3 bits of entropy per letter, so if you don't do something stupid then you should be okay with ciel(64/3) = 22 letters.

Regardless, 8 characters is not enough, as D.W. explained.

  • Thanks for the advice, I've been wanting to increase the password length for a long time now and I've just never bothered due to the number of devices that will need to be updated. But I've finally got around to asking, I'm probably going to stick with 16 characters just to give me a slightly larger buffer over the 12 character passwords which of course will be generated from a secure source. Commented Jun 6, 2012 at 19:24

There are a minimum of 2-3 ways I would address this.

IF the data in the network is protected by some type of regulation (HIPAA, PCI, etc.) then I would go overboard and do all of these. I'm sure there's more but that's all I can think of off the top of my mind.

  1. As many characters as you can suffer with.
  2. Turn off WPS since reaver can crack this in about 10 hours.
  3. Do wireless surveys for all of your AP's and turn down the power settings so that you cannot get signal from outside the building. (I use wireless analyzer for android on my phone or inSSIDER www.metageek.net/products/inssider/ for your laptop)
  4. Lock down MAC addresses (although they can be spoofed it would help deter skiddies)
  5. check out http://weaknetlabs.com they have some interesting theories on additional security for WEP/WPA.
  6. Audit your network access specifically looking at attempts to access and use an ACL to not allow more than X attempts for trying to connect.
  7. do not broadcast your SSID, again this will prevens script kiddies from attempting to access your network.

What is the make/model of your router?

  • #3 is fairly weak as a security measure. Whether or not your AP is "heard" depends more on the listener than it does your AP. It also has the potential to adversely affect authorized users. I don't suggest doing it.
    – Iszi
    Commented Jun 5, 2012 at 19:38
  • Addendum to my earlier comment: Regardless of whether your AP is tuned down or not, clients near the walls of your building (whose transmitting power is probably beyond your ability, or beyond practicality, to control) can still be easily heard. Again, it's more of an inconvenience to you to turn down your signal than it is an actual security benefit. The same could arguably be said for MAC address filtering, but you've already covered that.
    – Iszi
    Commented Jun 6, 2012 at 12:09
  • Luckily I'm not bound by any legal or corporate policies and this is simply a home network. Although I've heard that (correct me if I'm wrong) that turning SSID broadcasting off can be a bad thing as typically your Wifi device will wait for a broadcast and then connect, whereas if SSID broadcasting is disabled the device announces that it's looking for the access point named SSID and then any device can then say that it's my SSID. Of course I'll notice this but some of my family members will not. Commented Jun 6, 2012 at 19:22
  • These are just reccomendations, but in my deployments I design and harden the networks to make it most difficult for myself to pentest my way back in. Since it's a home based router if it supports DD-WRT I would load that up instead of the stock firmware and go from there. Granted the broadcasting of SSID could be debated, do what you are comefortable with based on your own research. I disable, same with hospitals and banks that I've worked with. A long password, disabling WPS and filtering MACS is WAY more than most home networks. I have seen some cases of running on channels 13 and 14 but
    – Brad
    Commented Jun 6, 2012 at 21:32
  • may not be legal to run on those channels in your region, but again if you are the only one capable of running on those channels, it would take some skill to attempt to connect without knowing how to overcome region limitations on hardware.
    – Brad
    Commented Jun 6, 2012 at 21:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .