Steve Gibson is recommending long, low-entropy passwords. This can give an advantage of convenience only in the short term. If there is a significant advantage to the password user, attackers will optimize for this type of low-entropy password by changing the search order.

Gibson implies in his reasoning that short passwords will be tried first. The efficient way to crack passwords is to try them roughly in the order of increasing entropy, not length. Increasing length is conventional, not essential.

Any gain in convenience you get by using long passwords with low entropy is lost when the attack methods change. Attackers adopt heuristics to target patterns in passwords, and you're back to relying on entropy. At that point, Gibson's approach just means uselessly typing more characters. The convenience gain is reversed.

Any public recommendation of a low entropy scheme, at any level of detail, is self-defeating. The more it's adopted, the faster it weakens relative to entropy.

Worse, if you were really getting the benefit of convenience by assuming dumb lexical order brute force attacks and using lower entropy than you should, you have to change your passwords to compensate for the loss of safety as the attack methods are adjusted to neutralize the length advantage.

Worse still, Steve Gibson is recommending low entropy for encryption keys, for example in WPA2 wireless encryption. When you use encryption for wireless transmission, you intentionally expose the cyphertext immediately, expecting it to be stored by keen attackers, and to be safe for some required period according to the strength of the key. In the long term, only the entropy of your key can reliably slow down decryption attempts. By the time you realize your key isn't as strong as you were led to believe, it's too late to change it. Your attacker already has your weakly encrypted data.

at technophobe: bad security advice: Steve Gibson's password haystacks

[from Seth, reposted by merriam] I don't understand your concern of Steve Gibson's "password padding"

I read his article found @ https://www.grc.com/haystack.htm. It makes a lot of sense. But he did say not to just add periods into your password to make it longer, but to come up with your own padding and make sure you have at least 1 each upper case, lower case, number, and symbol. If you build your own padding that has all 4 elements and is at least 10 digits long, would that not be pretty secure? For example...

[examples removed]

Are you saying that is an easy password to crack? I would love your followup thoughts on this.

Comment by merriam
Seth's examples

Seth, thanks for your comment. Your example passwords are safe for banking (and overkill for casual websites), as long as you don't discuss your scheme. I've cut the examples out of your comment in case they reveal to much about your actual passwords. That's unlikely, but I'm being careful.

You're using repetitions of long patterns inserted into conventional passphrases, which makes your examples much stronger than the short patterns shown on Security Now 303 at 76 minutes (YouTube) and Steve Gibson's website.

But the repetition doesn't help because it makes more work for you faster than it makes more work for the attacker. Your examples are over 30 characters long. You could probably choose a 10 character password without repetition that's quicker to type, harder to attack and no harder to remember.

Sorry for my slow response. Comments here are currently moderated, and the comment system doesn't allow me to edit your comment, so I've reposted it after a long delay.

I've improved and expanded this post. I hope it's clearer now.

Comment by merriam