How Many Seconds Would It Take To Crack Your Password? 454
DillyTonto writes "Want to know how strong your password is? Count the number of characters and the type and calculate it yourself. Steve Gibson's Interactive Brute Force Password Search Space Calculator shows how dramatically the time-to-crack lengthens with every additional character in your password, especially if one of them is a symbol rather than a letter or number. Worst-case scenario with almost unlimited computing power for brute-forcing the decrypt: 6 alphanumeric characters takes 0.0000224 seconds to crack, 10 alpha/nums with a symbol takes 2.83 weeks."
See you at the end of time (Score:4, Insightful)
Re:Has anyone actually doublechecked his security? (Score:5, Insightful)
That's why you enter something lexically similar to it and not the actual password. /. password is 3 mid-length words and the number 54 added to it, you type in that many letters and the number 11.
If your
Got "trillion trillions centuries" here :)
Which really means "lasts until some idiot stores it as plain text."
Interactive password tester? (Score:5, Insightful)
What a great way to generate a new wordlist...
Re:Poor security (Score:5, Insightful)
What system would allow someone to make thousands of attempts per second to login?
That's not the problem. The problem is that the lists of user logins and corresponding hashed passwords get in the wrong hands, whether it be due to bad design and/or coding, insecure software, or unfaithful servants. When you have that list, you run brute force against it to get the actual passwords.
Breaking into servers is much more attractive than breaking individual user accounts, simply because the yield is so much higher. Make a good trojan delivered through good social engineering, and you may catch 1% of the users. Breach the server, and you get the account info of all of them, and by running a crack session, you likely have 20-50% of the passwords within hours. Choose a very hard to crack password, and they may never get it even if they have the hash.
This happens a lot more than what we think. A server breach doesn't have to leave traces that anyone actually sees. We mostly know about the cases where the culprits brag about it or publish lists, which is unlikely to be more than the tip of the iceberg.
Companies are going to insist that their data is safe until proven otherwise, but you're stupid if you believe them.
Sony, Steam, LinkedIn, eHarmony - there are hundreds of server breaches with stolen user/hash lists that we know about. And likely an enormous amount we don't know about.
Re:This obvious is once again ignored... (Score:5, Insightful)
It's a terrible article. (Score:5, Insightful)
I wrote a nice long reply rebutting every single point then lost it when I hit backspace and focus was in the wrong part of the window. Grrr.
The author gets lots of things confused:
- He seems unaware that a rainbow table is equally effective against a good password as a bad one.
- He seems to think a dictionary attack comprises wholly and exclusively of words taken from a dictionary with no added numbers, symbols or punctuation. Bruce Schneier doesn't seem to agree with this [schneier.com], and I'm far more inclined to believe Mr. Schneier.
- He believes that a likely avenue for attack is constantly guessing a given user's password on a website. Any half-sane web service will block you long before you've tried a few thousand passwords against one username.
- He fails to note that in the case of LinkedIn, the list of password hashes itself was leaked - and this is Bad News.
- He also fails to note that in the case of LinkedIn, the password hashes were unsalted - Much Worse News.
- He also fails to note that if an unsalted list of password hashes is leaked, then it doesn't really matter how strong your password is, it's going to get found rather quickly. There's very little you or I can do about this. You could refuse to use systems that have such terrible security, but usually you only learn their security is this bad when it's far too late.
- He tops it off by recommending 10 character passwords with symbols and/or numbers. In other words, he falls foul of the problem described by Randall Munroe in XKCD [xkcd.com] some time ago.
Re:Huh. (Score:4, Insightful)
However, I noticed that he's not *checking* a dictionary file when evaluating password strength. The actual strength of a password like "spastic-elongated-kremlinitude" is pretty good, but his checker's figure of four hundred thousand trillion trillion centuries to crack with a high-end cluster is optimistic beyond the bounds of all reason. That would be naively building it up character by character, and *nobody* does naive character-by-character brute forcing for passwords that long. That's like building a skyscraper without power tools.
Re:obligatory xkcd.... (Score:5, Insightful)
let's say you know 100% for sure that somebody is using xkcd's method.
there are 15,222 words in the english language according to oxford english dictionary. how many are common 5, 6, and 7 letter words? hard to say for sure. I think 3000 or 4000 would be a good conservative guess, what do you think? let's say 3000 to err on the side of caution.
how many combinations of common 5,6, and 7 letter words does that give us to build a password based on xkcd's suggestion?
3000^4
that's 8.1 x 10^13 discrete combinations, counting the ability to reuse the same word.
I'm asuming you didn't build a plaintext dictionary with all those possible combinations... at 1 byte per letter, and an average of 6 bytes per component word, that's 4.86 x 10^14 bytes, or a 442 terrabyte dictionary file. where the hell are you storing that?
no, i'm assuming you probably built a program specifically to build combinations of component words and brute force using that. sure that will eventually work, after it goes through its 8.1 x 10^13 itterartions (worst case)... but hell, why are you trying to crack that hard a password when there are thousands out people out there whose password is just "Password1"? the club doesn't make your car theftproof, it just makes it less inviting to the thief than the car next to it. you don't need to outrun the lion, you just need to outrun the slowest person in your group.
and this is all assuming:
1. you somehow -know- which password generation method the person is using
2. they didn't do what I do with that method, and throw a few uppercase and numbers in there anyway.
Re:Huh. (Score:4, Insightful)
Pretty much everything you wrote is wrong other than your first line.
5 random lower case characters + one upper case = 52^6. It would be 26^6 if and only if you knew exactly where the upper case letter was, which is an unreasonable assumption. Adding an upper case letter would eliminate a straight lower-case dictionary attack entirely and double the pool of possible characters from 26 to 52. There are 6 places, so 52^6.
You make the same mistake in several other locations.
To address your other claim, "Adding one extra capital, number or symbol to a password does not increase password strength that much." ... You make this claim only because your math is so hilariously wrong.
Re:Huh. (Score:5, Insightful)
Based on what? You're arguing that Gibson is wrong, but your reasoning amounts to saying "nuh-uh".
The attacker knows that there are 6 characters in a password. Or does he? I'd want a hashing algorithm that hides the password length by turning any password length into e.g. a 64-character hash.
Even assuming he knows it's 6 chars, how can he know there are 5 lowercase + 1 uppercase? Assuming the hash doesn't give clues (which would be a weakness in the hash function) I see no way the attacker can infer 5 lowercase + 1 uppercase (and guess correctly at which position the uppercase will be).
Therefore he has to assume a search space of lowercase+uppercase for all positions, which leads to 52^6.
Re:Huh. (Score:4, Insightful)
The man is an idiot. Adding one extra capital, number or symbol to a password does not increase password strength that much. The algorithm assumes that all places in the password can be all characters.
Disagreeing with you doesn't make him an idiot.
Since we don't know what position a capital letter might occupy, I think we can agree that this expands the MAXIMUM search range above 26^6 and below 52^6+1. That's the teaching point the tool is designed for. It is not designed to be an accurate estimator, but more of a shock value tool to get the attention of users. It has some value in that role.
Re:Huh. (Score:5, Insightful)
5 random lower case characters + one upper case = 26^6 * 6.
6 random case random characters = 26^6 * 2^6 = 52^6.
Check your own math first.
Wait, what? (Score:5, Insightful)
With "almost unlimited" computing power any password will almost take "almost no time" to decrypt.
Is GRC some kind of trusted resource now? (Score:4, Insightful)
Slashdot always seems to be his willing dupe and publicizes whatever he is concerned with at the moment.
Re:Huh. (Score:4, Insightful)
Even taking Gibson's original category of all-lowercase alphanumeric, his time-to-crack figure is silly (in that it's not realistic):
36^6 = 2,176,782,336 possible combinations
0.0000224 seconds to crack (given by grc)
2,176,782,336 / 0.0000224 ~= 97,200,000,000,000
So, somebody is going to devote a supercomputer capable of trying 97.2 trillion passwords per second to cracking a password for some service that I'd use? Right...
For an idea of how big of a machine you'd need to try 97.2 trillion passwords per second, Toms had two high-end GPUs in SLI doing 1.5 billion per second, which means even with GPU acceration you'd need roughly 65,000 machines...
Re:Huh. (Score:4, Insightful)
Grandparent: 5 random lower case characters + one upper case = 26^6 * 6 NOT 52 ^ 6
Parent: 5 random lower case characters + one upper case = 52^6. It would be 26^6 if and only if you knew exactly where the upper case letter was, which is an unreasonable assumption. Adding an upper case letter would eliminate a straight lower-case dictionary attack entirely and double the pool of possible characters from 26 to 52. There are 6 places, so 52^6.
The grandparent poster has done the calculation correctly, if it is assumed that the cracker knows that there is exactly one uppercase character.
We're all agreed that if there is a 6-letter all-lower-case password, there are 26^6 possible passwords (26 possible character choices in each of six positions), right? For five lower case letters and one upper case letter, we draw five lower case letters (26^5 possibilities) and one upper case letter (26^1 possibilities, because it can't be a lower case letter), and we have 6 choices as to where in the password we place the upper case letter: 26^5 * 26^1 * 6 = 26^6 * 6 possible passwords.
Alternatively, consider our six-letter all-lower-case password and its 26^6 possibilities. We have a dictionary that starts aaaaaa, aaaaab, aaaaac and ends with zzzzzz. If we add exactly one (no more, no fewer) capital letter, then each entry in our original dictionary is replaced by six new passwords, one with a single capital letter in each position: Aaaaaa, aAaaaa, aaAaaa, aaaAaa, aaaaAa, aaaaaA, then Aaaaab, aAaaab, aaAaab, aaaAab, aaaaAb, aaaaaB, and so forth--again giving us 26^6 * 6 possible passwords.
That said, it would be unusual for our hypothetical cracker to have access to that sort of specific information about a password. Why would he know that there was exactly one upper case letter? Far more likely would be some sort of rudimentary password screen that required our password to contain a mix of capital and lower case letters--that is, at least one upper case, and at least one lower case. In that more-likely scenario, the parent's calculation is closer to the mark. Each of six positions could have any one of 52 values (26 upper- and 26 lower-case letters), giving 52^6 possibilities, from which we subtract 2*26^6 options, representing the forbidden all-lower-case and all-caps passwords, leaving 52^6-2*26^6 possible choices.