# Why are low-entropy passwords considered OK in many cases?

When talking symmetric encryption, a 56 bit key is known to be so weak. If you use it for your encryption, you are considered a goner as you wont survive brute-force.

When talking passwords however, the standard these days is about 8 characters selected from about 94 characters on the keyboard. This translates to about 94^8 possible passwords, which means about 52 bits of entropy.

Now, 52 bits is obviously less than 56 bits. But somehow a 56 bit key is considered weak while a 52 bit password is considered safe (i.e., many systems force you to use the 8 characters). Why is this so; I mean why are the standards lower when we talk passwords yet both passwords and keys are subject to the same kinds of brute-force attacks?

I know that humans would find it impossible to maintain a 128 bit password -- however, I wonder if there is some technical reason why a 52 bit password would not be as weak as a 52-bit encryption key for that matter.

• For anything that you really care about, 8 characters is not sufficient nowadays. What gives you the impression that 8 characters is sufficient? Jun 5, 2016 at 4:27
• A 12 character password would still be 78 bits; which is again much less than 128 Jun 5, 2016 at 4:59

"Cracking" a password on a website is not `subject to the same kinds of brute-force attacks` as encryption keys. Unless your source is a breached database, the rate at which you can brute force is limited by the website, which can introduce source-based throttling or blocking, attempt limits, raise flags etc. which makes a simple brute force harder to do.

However, if hashes have been leaked and there is insignificant additional entropy, then 8 character passwords are not secure, as @Lie Ryan suggests.

There is a difference between a password (passphrase) and an encryption key. Both are used for different purposes. In case a password is used directly as an encryption key it will never be considered secure, just as you described.

In many cases you can see KDFs in place, to derive cryptographically strong keys from user passwords (typically PBKDF2 (or even better, memory-hard KDFs, i.e. scrypt)). This approach will also limit the attacker's ability to perform a efficient brute-force attack on the password. One example might be WPA2-PSK.

The above paragraph was just an example, to show the difference. There can be other measures how to prevent brute-force attacks on passwords (retry limits - typically seen with smart cards (PIN), captchas, etc.). It depends on the concrete scenario. However, in case you get hold of a cipher text, nothing stops you to try and brute-force the actual encryption key and that is why this keys have to be strong.

The requirement for complexity depends on the lifecycle of a secret (and the value of the secret). If the lifetime is very short because it expires and/or is renewed on a regular basis, not the same level of complexity might be necessary.

An account lockout might shorten the lifetime of a password immediately. If an attacker is able to approach just 5 guesses before this is happening, even a short numeric PIN might be enough: It is impossible to run through the whole key space anyway.

But encryption usually works differently. If an attacker is able to intercept and record encrypted data, he might have “all the time of the world“ to guess the right password. Even if from now on a different encryption key is set, which would not affect earlier encrypted data. This is why encryption keys tend to expect much more complexity.

• What about stolen password databases? They can be brute-forced offline. That happens frequently enough to be a considered case. Jun 5, 2016 at 14:02
• @ColBeseder, exactly. Rainbow tables online easily look up hashes for most 8 character passwords within a few seconds.
– Jedi
Jun 5, 2016 at 16:28
• If the passwords are salted and the salt is kept secret, deciphering the passwords takes a lot of effort. I'm talking about lifetimes. Rainbow tables are usually not created for multiple salts and therefore useless in such a case. Jun 5, 2016 at 17:49
• Good luck brute-forcing Argon2 or even scrypt hashes.
– bayo
Jun 5, 2016 at 20:40