GRC haystack

@thorsheim has been pestering me to start a blog and I have given in since twitter is a bit limiting.

The GRC haystack is the subject of this post.  Both @itinsecurity and @thorsheim asked for my remarks.

Directly speaking entropy for passwords is quite important.  However, there are a lot of variations on how to construct a good password.  Keyspace in some cases, as Steve Gibson claims in this specific case, may actually be more important.  The argument on its face is designed to be counter-intuitive in order to convince you to buy into his insight.

Entropy in a password is hard to estimate unless the password is truely randomly generated.  Keyspace is much easier to measure.  However, Gibson's claim relies on several premises:
1) the user constructs a padding system that increases length and thus keyspace
2) the padding scheme remains unknown to an attacker
3) the attacker therefore can only attempt a dumb bruteforce attack

Premise 1 relies on the user to construct some padding system that is to remain secret, thwart the attacker, and its re-use is encouraged.  The fact that many applications still store plaintext passwords means that re-use of the padding scheme is an extremely bad idea.

Given what we already know about user behavior is that any ending characters or "padding characters" will likely be of low entropy.  I would assume that users would be likely to pick a single character for padding and use it.  This would render the scheme effective against current rainbow tables but useless against any per position brute forcers designed for exactly this sort of attempts to foil the attack.  Additionally, users really dislike additional keystrokes such as shift so they aren't going to go for complex patterns of padding characters.  At most this scheme means you might stay ahead of brute forcers and rainbow tables until the scheme enters common use and becomes known due to yet another application leaking plaintext passwords.  Also, it will encourage users to create shorter length high entropy passwords because the padding characters will "save them."

I've already touched on premise 2 a bit but it bears repeating that this scheme only works if it can't be guessed, realized, disclosed, etc. to an attacker.  Try convincing a user to type several iterations of <;> at the end of a password and they will just use a lot of 0s or anything that requires no shift.  Oh, and the user needs to remember how many of these padding sequences they use and repeat them later.

Premise 3 completely falls apart given either premise 1 or premise 2 falling apart.

Now, lets discuss counter-intuitive schemes like passphrase construction that don't actually use low entropy to increase keyspace.  Systems such as diceware passphrase creation are a much better idea.  Oh, and don't re-use those passwords since you should assume that at least one application you use is irresponsible in its passowrd storage.

Unfortunately, most users take any security advice they are given and snake oil solutions are embraced without a second thought.  Suggestions such as the GRC haystack are yet another example of bad advice from "security professionals" that likely will be followed by some users.  There are many ways to make better passwords but this scheme is not one of them.