I did not intend to spend so much time on this topic but @itinsecurity had the time to listen to the 37 minute podcast and the claim is this padding scheme is immune to rainbow tables. I intentionally did not do rainbow table analysis because I already had a long post. Also, to even enter this discussion we have to assume the application in question does not store passwords plaintext and instead hashes them. Additionally, we assume the attacker already has all the hashes.
Lets start with
password: Summer
[A-Za-z][a-z]{5}
52^1 * 26^5 which is roughly 2^29.203
Lets pick some potential padding characters: [., ]. Alright how about the character sets:
[A-Za-z][a-z]{5}[a-z., ][., ]{1,4}
52^1 * 26^5 * 29^1 * 120 which is roughly 2^40.968
length 8 to 11
[A-Za-z][a-z]{5}[a-z., ][., ]{1,8}
52^1 * 26^5 * 29^1 * 9840 which is roughly 2^47.325
length 8 to 15
Perhaps users will cease to append years to the end of the password and add a padding character every password change? Alright lets go for larger character sets:
[A-Za-z][a-z]{5}[a-z.,<->\*\[\] ][.,<->\*\[\] ]{1,4}
52^1 * 26^5 * 35^1 * 7380 which is roughly 2^47.181
length 8 to 11
Does this mean it is rainbow table proof? Hardly. It just means traditional tables may not be useful but plenty of options exist to defeat them: length, unicode, etc. Sure some users may put padding at the beginning, at the end, make it really long, etc. but this just gets silly. Using 4 randomly selected words from diceware's list gives you 7776^4 or 2^51.699 and that's purely lower case, no padding, no symbols, etc. Average length of a word is 4.2 characters.
2011-06-14
2011-06-13
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.
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.
Subscribe to:
Posts (Atom)