Cracking SHA1 with EC2 GPU instances.

H_TeXMeX_H · 12-04-2010, 03:54 AM

I know you guys like to do these mathematical calculations that prove that it's impossible to crack this, but I think there should be a field that deals with the human aspect. I'm quite positive that most people will use very weak passwords, either from a dictionary, or from their personal details (birthday, son/daughter's name, etc). The above calculations apply to the best case scenario, but this is never the case.

win32sux · 12-04-2010, 12:55 PM

Quote:

Originally Posted by Matir

FWIW, it's essentially irrelevant to consider the minimum length for purposes of calculating runtime. A better way to approach things is to include one more character than there really is as a sort of "null" byte (e.g., a 7-character password can be considered to be an 8-character password with one byte set to NULL).

Your value for 12-36, 94 character set is about 2^235.981. Using the 95 "character set" for length 36 (e.g., 95^36) is about 2^236.514. As you can see, it's pretty close. If you want to get really precise, use the original character set for the minimum length and the +1 for the remaining characters. For example, 94^12*95^(36-12) yields a value of 2^236.332. Of course, just using 94 characters for 36 places (94^36) yields 2^235.965.

The reality is that the largest term dwarfs the smaller terms by so much that it becomes the dominating factor. You can see that in the A-Y values you posted, each one increases by 2 digits, or an approximate factor of 100.

Thanks for the tips, Matir!

Quote:

Originally Posted by H_TeXMeX_H

I know you guys like to do these mathematical calculations that prove that it's impossible to crack this, but I think there should be a field that deals with the human aspect. I'm quite positive that most people will use very weak passwords, either from a dictionary, or from their personal details (birthday, son/daughter's name, etc). The above calculations apply to the best case scenario, but this is never the case.

The formula I googled simply tells you the total possibilities for a password, given the character set and the policy's min/max length. This should not be interpreted as an attempt to prove/disprove how crackable/uncrackable a password is. Rather, it's a way to gauge how much work a brute force attack may need to do when it encounters a strong password. I do understand that unfortunately most human-generated weak passwords won't even need a brute force attack to get cracked, but the article linked in the OP isn't about dictionary or guessing attacks AFAICT.

Matir · 12-04-2010, 02:47 PM

As win32sux says, the article was about brute forcing.

If you want to look at the "randomness" (called entropy) of a given password, look at Shannon Entropy and the NIST 800-63 guidelines. For a user chosen password, the first character gives you 4 bits, characters 2-8 buy 2 bits each, 9-20 are 1.5 bpc (bits per character) and 21+ are only worth a single bit each. (These values assume the system doesn't enforce dictionary checking or composition rules.) A random ASCII password, by the way, is about 6.5-6.6 bpc. As you can see, humans choose poor passwords, myself included. I just like to make the password secure enough that people who aren't targeting me specifically will give up. (Excluding system passwords, root passwords, banking applications, etc.) But my password to, say, New York Times online, is, in comparison, pitifully weak.