Password Strength

bbking13 - interesting article.

As the OP for this thread, I said I would post some results back once I'd done some testing. But first it's probably worth stating that what we're looking at (we being a large commercial organisation which is not highly regulated except in HSE) is a file-level password/encryption policy for files classified as Confidential (or at least, which should be!). We don't handle volumes of PII as a matter of course like Health, Gov, and Finance/Banking.

Then we have the question of who we're trying to protect against (how good is good enough), and the feeling is that we want to protect our files against the 'casual' thief or observer e.g. someone steals or otherwise comes into possession of one of our laptops or USB devices and starts poking around in data files. We think that a casual thief might have some free or cheap cracking software on their own computer, but not specific hardware (e.g. graphics accelerators) and expensive commercial software - we don't think we're likely to be the subject of a determined and targeted bid to steal specific files; don't blame the messenger, folks!

So far, the outline policy says use any native password protection, otherwise use 7Zip (free, so no license issues, right?) and encrypt there; so AutoCAD files, FEA models, 3D wireframe models etc are protected. Device encryption is covered as well, but we know that some users won't have device encryption.

So - passwords strength. I have PRTK in the office and Passware Basic Edition at home, I used default settings in both to try and crack Word 2010 open-protected files. Having cracked some passwords for internal use about three years ago in minutes using PRTK, I was confused when initial attempts to crack really simple passwords were not succeeding even after several hours.

For example, "Abcc" took 9hr 58mins in PRTK. So I converted the .docx file to .doc - bingo, 2 seconds to crack. So the first lesson for me is that Office 2007/2010 passwords are WAY more secure than Office 2003 and earlier. Passware meantime, when I left it chuntering away at home this morning, was predicting 4 days to crack Abcc………… At what point would a casual thief/observer give up? Rhetorical question.

FYI my home system is an Athlon II X2 260 3.20Ghz machine with 4GB RAM running Win7 64-bit
The office system is and INtel Core Duo P8600 2.60Ghz with 8GB RAm running Win7 64-bit

I will report back on longer and more complex passwords, but I kinda expcet that 8 characters is going to be plenty for Office 2010 and 7Zip.

Unless, of course, you guys know different!

Cheers

Ex- Which of the following two passwords is stronger,
more secure, and more difficult to crack?

D0g…………………

PrXyc.N(n4k77#L!eVdAfp9

"In fact, since it is one character longer and contains uppercase, lowercase, a number and special characters, that first password would take an attacker approximately 95 times longer to find by searching than the second impossible-to-remember-or-type password!"

Yeah sure, unless a "repeat pattern" is detected, come on…..

password D0g…………………
entropy 20.9
crack time (seconds) 97.852
crack time (display) 3 minutes
score from 0 to 4 0
calculation time (ms) 1

password PrXyc.N(n4k77#L!eVdAfp9
entropy 136.046
crack time (seconds) 4.4964660849471965e+36
crack time (display) centuries
score from 0 to 4 4
calculation time (ms) 1

As said, there is not only "brute force".

jaclaz

I don't think he says entropy is not important. You could just pad a strong password to make it even better.

What can I use to detect repeat pattern?

Here's a super easy to remember password with some slight padding if you want to crack

MD5 =

c38c60de32455c0fcb56f844c1f2483d

@jaclaz, what did you use to measure strength above?

@jaclaz, what did you use to measure strength above?

The already mentioned several times thingy here
https://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.html

(mind you it's just one of the "n" ways to measure strength of a password, not necessarily "better" than any other)

jaclaz

@jaclaz, what did you use to measure strength above?

https://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.html

This is a 'fun' tool but I am not convinced by it's results. It claims instant results of matching for maybe common words, and even a few numbers. My concern is this may be possible if you know the password is 17 characters long, but otherwise you have to test all passwords of maybe 3-16 characters as well.

The brute force times - I presume not looking for words gets into months with 12 characters (on the Haystack link).

I am sure if you know the style of password speed will be increased

This is a 'fun' tool but I am not convinced by it's results.

Sure, and the Author has made explicit and in extreme details the reasoning behind it, the actual limits of the model, and also provided the source code
https://tech.dropbox.com/2012/04/zxcvbn-realistic-password-strength-estimation/

And even without going through the code, the Conclusion is clear enough

Conclusion

At first glance, building a good estimator looks about as hard as building a good cracker. This is true in a tautological sort of way if the goal is accuracy, because “ideal entropy” — entropy according to a perfect model — would measure exactly how many guesses a given cracker (with a smart operator behind it) would need to take. The goal isn’t accuracy, though. The goal is to give sound password advice. And this actually makes the job a bit easier I can take the liberty of underestimating entropy, for example, with the only downside of encouraging passwords that are stronger than they need to be, which is frustrating but not dangerous.

Since you have no way to know what tools (and approaches) a hypothetical cracker might use, any and all measurements are "relative", and as seen with the example of a set of non-English words, very variable (the tool having only a - I presume limited - English dictionary will under-estimate correcthorsebatterystaple and over-estimate correttocavallopilagraffa - the Italian equivalent, )

password correcthorsebatterystaple
entropy 45.212
crack time (seconds) 2037200406.475
crack time (display) 65 years
score from 0 to 4 4
calculation time (ms) 1

password correttocavallopilagraffa
entropy 63.621
crack time (seconds) 709480909201034.2
crack time (display) centuries
score from 0 to 4 4
calculation time (ms) 1

As soon as you have them in a dictionary, they will become both m00t.

Also, as seen, there are two completely different "scopes" (and consequently "approaches").

We are more oriented to have the kind of problem of the kind

Break into this specific account or break this specific password protected file/whatever.

While the test done by arstechnica was of the kind

Find the more passwords among these.

If we limit ourselves to a simpler set word-word (12 letter long wink )
password twelveletter
entropy 20.348
crack time (seconds) 66.716
crack time (display) 3 minutes
score from 0 to 4 0
calculation time (ms) 1
and we use instead a "random" pattern (still 12 letter long)
þßhrÓ͞ʮŒwÒ
password þßhrÓ͞ʮŒwÒ
entropy 70.592
crack time (seconds) 88959870911976660
crack time (display) centuries
score from 0 to 4 4
calculation time (ms) 0
we can appreciate the difference (this second one is "entirely" brute-force and uses the widest possible charset).

The point I was trying to make is, as long as we avoid known words by transforming them, how difficult is for the cracker to recognize the transformation pattern, or if you prefer how "random" does such password become?
password svdkudmfuufs
entropy 56.405
crack time (seconds) 4771447833084.08
crack time (display) centuries
score from 0 to 4 4
calculation time (ms) 1

jaclaz

Interesting that "2B or not" comes up just 29 days, but the shorter password "2B or n" comes out to four months.

If 29 days and 4 months are both a 3, there is somet5hing wrong with the scale.
Maybe 2 should equal anything in days, 3 should equal anything in months, 4 should be years.

IMHOW/.02

@Astro
Well not a surprise "not" is "dictionary", "n" is "brute-force".

If 29 days and 4 months are both a 3, there is somet5hing wrong with the scale.
Maybe 2 should equal anything in days, 3 should equal anything in months, 4 should be years.

IMHOW/.02

Well that obviously depends on how the scale is made.

I would say that 0 to 4 is a bit "too compressed" as a scale.

From the source code
https://github.com/lowe/zxcvbn/blob/master/scoring.coffee

crack_time round_to_x_digits(crack_time, 3)
crack_time_display display_time crack_time

and

crack_time_to_score = (seconds) ->
return 0 if seconds < Math.pow(10, 2) ; <- 100 seconds
return 1 if seconds < Math.pow(10, 4) ;<- 2.77 hours
return 2 if seconds < Math.pow(10, 6) ;<- 11.57 days
return 3 if seconds < Math.pow(10, 8 ) ;<- 3.17 years
return 4

Points from 0 to 9 or from 0 to 19 would make more sense IMHO.

There is also something "flaky" in this other snippet, seemingly

display_time = (seconds) ->
minute = 60
hour = minute * 60
day = hour * 24
month = day * 31
year = month * 12
century = year * 100
if seconds < minute
'instant'
else if seconds < hour
"#{1 + Math.ceil(seconds / minute)} minutes"
else if seconds < day
"#{1 + Math.ceil(seconds / hour)} hours"
else if seconds < month
"#{1 + Math.ceil(seconds / day)} days"
else if seconds < year
"#{1 + Math.ceil(seconds / month)} months"
else if seconds < century
"#{1 + Math.ceil(seconds / year)} years"
else
'centuries'

In the example posted by Astro the
crack time (seconds) 2398181.402
translates to
crack time (display) 29 days

Here, 2398181.402/(60*60*24) makes 27.75 days, let's say rounded 28, but there is still an additional day…

jaclaz