Security Basics mailing list archives
Re: Passwords: length vs. complexity
From: Ansgar -59cobalt- Wiechers <bugtraq () planetcobalt net>
Date: Mon, 21 Jul 2008 21:14:11 +0200
On 2008-07-21 Rivest, Philippe wrote:
I already addressed this point in my previous mail. The strength of your password or passphrase isn't necessarily determined by the number of characters in it, but by the number of tokens. If your 35 character passphrase consists of 7 words, then its strength isn'tHow can one know what kind of tokens were used?
How would someone gain insider knowledge? Former employee, someone overhearing you talking about how you choose your password, subscriber to this list, ...
I mean beside the fact that you may have enough storage space and processing to store and use a rainbow table for 15+ token, how would you identify if a password is 1- Character only 2- Complexity 3- Length 4- Tokens are words or single alpha/num/special
See above. Always consider an attacker with inside knowledge. Otherwise your measures may turn out to be obscurity rather than security.
If I were to get a hashed password (maybe I'm weak in this area) I wouldn't be able to identify what was used to create it. So I would have to choose the technique to best crack it. Brute forcing it, rainbow table or even a dictionary attack.
Usually an attacker doesn't come across hashes by chance, thinking "Oh, my, lookit this: a hash! Let's crack it!!1!"
I could with a lengthy password bypass most of these, unless I'm mistaking. Brute forcing would have to test every permutation possible, with length you would have a lot, that would be (without knowledge) length^tokens_used (15^94 for exemple or 15^300). This could take too much time.
I don't assume an attacker with zero knowledge. Unlike you, apparently.
Rainbow table, you would have to get the full range of possible hash and this would take a lot of space and time to compute & process as you would have to get all the possible hash for all the lengths.
With rainbow tables you trade time for space. That's how they work.
And where would you stop? I mean if you have a rainbow table for up to 8 char/tokens, if I have 9 your attack wont work. So the longer I go the more I can resist.
Weren't you the one saying that most users can't remember passwords with more than 8 characters? I don't see how a passphrase with more than 8 tokens would be any different in that respect. Also an attacker won't neccessarily have to crack your password. An attacker will usually go for the weakest link. Cracking one password may suffice, even if it's not yours.
And for dictionary attack, well a bit of complexity would get thru that one.
It is no problem at all to modify dictionary attacks to cover "popular" replacements, like l337-sp34k or something. That'll take some more time than a plain dictionary attack, but still way less than a brute-force attack.
Yes, when users choose bad passwords, entropy will decrease. How does that affect *random* passwords?Well, I rarely see *random* passwords. I usually see user chosen password and you then know they are weaker.
Regardless of what you rarely or not-so-rarely see I did expressly talk about randomly chosen passwords. Could you please read first what you're responding to? Thank you.
For some reason our users here seem to be able to memorize strong passwords (10+ characters, mixed case, digits, special characters). We must've be hiring only geniuses. Or, it could be because we explain to our users why random passwords are important. Take your pick.I don't know where you work; seriously where I have worked b4 even sys admin had a hard time remembering the password for all the resources they used. We had to use tools that would store & encrypt them, which is by far what normal user would do.
Yes. So? We're doing that as well. It's perfectly fine to memorize only one (strong) password and store all other passwords in an encrypted vault. [...]
Of course I do. Security measures are only secure if they can also ward off an attacker who has inside knowledge.I know that encryption and hash should to be able to withstand any attack even if all knowledge about the system and process is known beside the key used. (I don't remember the name of the guy who said that for encryption)
It's called "Kerckhoff's Principle", named after the dutch cryptographer Auguste Kerckhoff.
I could easily fool that "attack" by using very known mistakes Password 1) My password is very strong Password 2) Mypasswordiseverystrong Password 3) my pasword is verry strong Password 4) My very strong password Password 5) My password is very strong Password 6) My PaSsWoRd Is VeRy StRoNg (I had a friend (RBF_GIRL) who would always type like this. Sup rbf!) ...#5 is error- prone and thus unlikely to be used (at least by those users we are talking about).#5 is not more or less prone to errors then $8a£l|
I disagree. IMO counting whitespace in a (long) passphrase *is* more error-prone than typing a (shorter) sequence of distinct characters. At least for those users who wouldn't use a password like "$8a£l|" in the first place, because it's too hard to memorize. Which AFAIR is the group of users we're talking about.
It is a normal phrase, and each words gets + 1 space. If you don't like my example you may find something that suits you better. But I can remember to hit my space bar +1 time for a 5 (only 4 words counts space wise) word sentence.
Your example had 2-3-1-5 spaces. That's not +1 space for every word. Not to mention that the latter could most easily be included into the algorithm of a password cracker.
And for the record, I do want to stress out that user training should be the first thing you think when you talk about strength of a password.
Umm... yes. That was the bottom line of my previous mail.
I'll take this with one last example; security is a trade off to between what is possible and its cost. Strong password thru complexity is possible, but at higher cost then length (user cost (mental or training), policy cost and so on).
I'd like to see some actual (verifiable) numbers supporting that claim. No, the URLs you mentioned before don't count. They didn't make the data of their studies available, so it's impossible to verify their claims. Not to mention that I don't agree with the basic implicit assumption in several of those articles that users who'd chose a predictible password would magically not chose a predictible passphrase. Besides, that still doesn't change anything at all about length being equivalent to complexity. Which still is all that I said in my first mail. Regards Ansgar Wiechers -- "All vulnerabilities deserve a public fear period prior to patches becoming available." --Jason Coombs on Bugtraq
Current thread:
- Re: Fwd: How does the Cain and Abel SAM dump works?, (continued)
- Re: Fwd: How does the Cain and Abel SAM dump works? Adriel Desautels (Jul 15)
- RE: Fwd: How does the Cain and Abel SAM dump works? Eric Snyder (Jul 15)
- Re: Fwd: How does the Cain and Abel SAM dump works? Adriel Desautels (Jul 15)
- Re: Fwd: How does the Cain and Abel SAM dump works? Jorge L. Vazquez (Jul 16)
- Re: Fwd: How does the Cain and Abel SAM dump works? Dave Hull (Jul 16)
- Re: Fwd: How does the Cain and Abel SAM dump works? Ansgar -59cobalt- Wiechers (Jul 16)
- Message not available
- Passwords: length vs. complexity (was: How does the Cain and Abel SAM dump works?) Ansgar -59cobalt- Wiechers (Jul 18)
- RE: Passwords: length vs. complexity (was: How does the Cain and Abel SAM dump works?) Rivest, Philippe (Jul 21)
- Re: Passwords: length vs. complexity Ansgar -59cobalt- Wiechers (Jul 21)
- RE: Passwords: length vs. complexity Rivest, Philippe (Jul 21)
- Re: Passwords: length vs. complexity Ansgar -59cobalt- Wiechers (Jul 21)
- Message not available
- Re: Passwords: length vs. complexity Ansgar -59cobalt- Wiechers (Jul 22)
- Re: Fwd: How does the Cain and Abel SAM dump works? Adriel Desautels (Jul 15)
- Re: How does the Cain and Abel SAM dump works? Rob Thompson (Jul 18)
- Re: How does the Cain and Abel SAM dump works? Ansgar -59cobalt- Wiechers (Jul 16)
- RE: How does the Cain and Abel SAM dump works? Rivest, Philippe (Jul 16)