Re: Passwords: length vs. complexity

[Ansgar -59cobalt- Wiechers <bugtraq () planetcobalt net>]

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't
>
> How 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