On 2008-07-21 Kurt Buff wrote:
> The number of tokens available, when using old-style passwords, is on
> the order of, as you pointed out earlier, 26-36, correct?
Rather 90-95 (62 alphanumeric characters plus a number of special
characters). If we're talking about strong (randomly chosen) passwords,
that is.
> The number of tokens, when using larger passphrases, and counting
> entire words as tokens, delimited by spaces (and not counting
> punctuation or special characters or capitalisation, and choosing
> English as the base language, all of which are fairly large caveats, I
> believe) becomes on the order of 10,000 to 20,000 commonly used word
> out of about 1,000,000 or so in the English language, or more if
> including specialized vocabularies, such as names, sports terms, and
> less-common technical vocabularies specific to industry or job
> function, etc.
The Technet article [1] Philippe referred to mentioned numbers from 300
to 50000-70000.
> Even if one accepts that the keyspace will be (severely) limited by
> people choosing sentences with standard syntax and grammar, and by
> choosing smaller and easier-to-type words, this still seems to be a
> huge win over using randomized-but-smaller passwords that are hard to
> remember and hard to type.
Perhaps. As I already said in my second last mail, even passphrases
with 5-7 words taken from a 300-word dictionary may be secure enough.
They're just not as secure as the proponents of passphrases make it
sound.
> If one sets a minimum passphrase size of, say 20 characters, and
> enforces complexity requirements that are standard in Windows (three
> of the following four: UC characters, LC characters, numbers, and
> punctuation and other special characters), then the passphrases will
> be essentially invulnerable to rainbow tables, and far superior to
> standard passwords from an end-user standpoint because of ease of
> recall and input.
Will they really? I have my doubts about it. In another article Philippe
referred to [2], Roger Grimes lined out some problems with conventional
passwords:
| And because most users also use dictionary words as the root to their
| "complex" password, and follow other common conventions (capitalized
| letters are at the beginning, numbers are at the end)
IMHO the same users will not magically stop making the same mistakes
when being forced to use passphrases instead of passwords. They'll use
simple words in simple sentences, applying the grammar and punctuation
they learned in school. I don't have actual numbers on this, but AFAICS
that should reduce the number of possible password significantly.
As for rainbow tables, there are better ways to deal with them than
password requirements (salted hashes in particular).
Don't get me wrong, I'm by no means opposed to using passphrases, and I
agree that they probably are easier to memorize for Joe Average. I'm
just not convinced that they are a silver bullet like some people say.
> The number of tokens available, when using old-style passwords, is on
> the order of, as you pointed out earlier, 26-36, correct?
Rather 90-95 (62 alphanumeric characters plus a number of special
characters). If we're talking about strong (randomly chosen) passwords,
that is.
> The number of tokens, when using larger passphrases, and counting
> entire words as tokens, delimited by spaces (and not counting
> punctuation or special characters or capitalisation, and choosing
> English as the base language, all of which are fairly large caveats, I
> believe) becomes on the order of 10,000 to 20,000 commonly used word
> out of about 1,000,000 or so in the English language, or more if
> including specialized vocabularies, such as names, sports terms, and
> less-common technical vocabularies specific to industry or job
> function, etc.
The Technet article [1] Philippe referred to mentioned numbers from 300
to 50000-70000.
> Even if one accepts that the keyspace will be (severely) limited by
> people choosing sentences with standard syntax and grammar, and by
> choosing smaller and easier-to-type words, this still seems to be a
> huge win over using randomized-but-smaller passwords that are hard to
> remember and hard to type.
Perhaps. As I already said in my second last mail, even passphrases
with 5-7 words taken from a 300-word dictionary may be secure enough.
They're just not as secure as the proponents of passphrases make it
sound.
> If one sets a minimum passphrase size of, say 20 characters, and
> enforces complexity requirements that are standard in Windows (three
> of the following four: UC characters, LC characters, numbers, and
> punctuation and other special characters), then the passphrases will
> be essentially invulnerable to rainbow tables, and far superior to
> standard passwords from an end-user standpoint because of ease of
> recall and input.
Will they really? I have my doubts about it. In another article Philippe
referred to [2], Roger Grimes lined out some problems with conventional
passwords:
| And because most users also use dictionary words as the root to their
| "complex" password, and follow other common conventions (capitalized
| letters are at the beginning, numbers are at the end)
IMHO the same users will not magically stop making the same mistakes
when being forced to use passphrases instead of passwords. They'll use
simple words in simple sentences, applying the grammar and punctuation
they learned in school. I don't have actual numbers on this, but AFAICS
that should reduce the number of possible password significantly.
As for rainbow tables, there are better ways to deal with them than
password requirements (salted hashes in particular).
Don't get me wrong, I'm by no means opposed to using passphrases, and I
agree that they probably are easier to memorize for Joe Average. I'm
just not convinced that they are a silver bullet like some people say.
[1] http://technet.microsoft.com/en-us/library/cc512609.aspx
[2] http://www.infoworld.com/article/06/07/21/30OPsecadvise_1.html
Regards
Angar Wiechers
--
"All vulnerabilities deserve a public fear period prior to patches
becoming available."
--Jason Coombs on Bugtraq
[ reply ]