Hacker News new | comments | show | ask | jobs | submit login

> The hash - 27934e96d90d06818674b98bec7230fa - was resolved to the plain text password 900gage!@# by Bestuzhev.

What? How did they crack this if brute force failed? That's scary as hell.

Not only that: "Kaspersky analyst Dmitry Bestuzhev cracked the hash for the password Sept. 17 just hours after Symantec put out a public request for help"

How is it possible to crack 900gage!@# in a few hours?

I run cloudcracker.com, which would have gotten this pretty quickly.

If you look at public password compromises, the components of this password "900", "gage", and "!@#" each appear pretty frequently. So using a data-driven approach to build context free grammars based on real-world passwords you've found or already cracked will get passwords like this every time.

Basically, everyone thinks they're clever when they choose a password, but for the most part people are all being "clever" in the same way. If you think up your password, chances are you've lost.

Thanks for your reply, Moxie! How would cloudcracker fare against the four-word combos recently popularized by xkcd[1]? Even if it were known that the password was made up of four English words, what sort of time frame might it require to crack?

1 http://xkcd.com/936/

The comic claims an entropy of 44 bits for a 4-word phrase. That means 11 bits per word, so a dictionary of 2048 words, which sounds reasonable for "common English words".

A single ATI 5970 can compute 2300M SHA-1 hashes per second. So you're looking at about two and a half hours to run through the entire keyspace. Fewer on a farm (which Amazon will rent to you for a few bucks). That's assuming you know the dictionary, of course.

Of course, if the password is hashed with bcrypt or scrypt it will take much longer, although I'm not sure how to do that calculation.

Assuming you knew the dictionary and just wanted to add entropy, get a bigger dictionary. A sample one I downloaded has about 7261 unique 4-letter words, or about 16,920 5-letter words, combined it's 24,181 words. Between four and six letters there's 56,099 words.

Each of those sets will bring you up in entropy, from two quadrillion up to nine quintillion permutations. That would take the ATI 5970 about 4306184595 seconds, or 136.4 years. If you spread that out over 100 cards that would only take you 1.3 years to crack.

Maybe that's too close to call, so you can always change your password every 60 days to mitigate people with more money/time on their hands. If anyone ever wants my password that bad they should just give me the money they'd spend on cracking and i'll give them my password ;)

  $ cat final/english-words.* | perl -le'@wl=map{ s/\s//g; tr/A-Z/a-z/; (/^[a-z0-9]+$/ and length$_ > 3 and length$_ < 7) ? $_ : () } <>; push @a, $wl[int rand(@wl)] for 1..4; print "@a"'
  rymmes weekly calvin cimbal

you're looking at about two and a half hours to run through the entire keyspace

That's a little faster than howsecureismypassword.net's estimate (154 octillion years on a desktop PC to crack "correct horse battery staple" (without quotes)).

Yes but don't forget the other part of his sentence : That's assuming you know the dictionary, of course.

It's pretty likely you do. Just take the N most common English words, and retry with a higher N if that doesn't work. That will crack "correct horse battery staple" quickly.

I think that's totally on the right track, but if people start to do that, chances are that they'll start to create exploitable patterns again (maybe they already exist, I don't even really keep track of how my password cracking dictionaries are evolving).

What I recommend is that people use diceware (http://www.diceware.com) to create a six-word passphrase, which they use to secure a password manager. Then use the password manager to generate random 12-character (alpha+numeric+symbol) passwords for each login.

Thanks for the followup, Moxie! Very much appreciate such an informed opinion. I've been following your recommendation, albeit with KeePass instead of Diceware. I have purposely avoided any sort of integration with browsers or closed-source software; security certainly trumps convenience or features.

Four English words chosen with a truly random generator will obviously give 4 times log(<size of dict>) bits of entropy. Four English words that you came up with yourself is different. I'd choose "sky blue ice dawn" :)

The nice thing about this technique is that it's pretty easy to remember randomly selected words. But even if you think them up yourself, you probably don't substantially shrink the key space an attacker has to search through as long as you avoid grammatical structures and words that have obvious connection to you.

I have a tool for generating passwords, be interesting to get a professional's opinion, if you have a minute :-) https://github.com/gaiustech/MkPasswd

Unrelated to your post, is your username a reference to the soda "Moxie"? If so, do you actually enjoy it?

AV companies like to share samples with each other, so guessing they had at least a bit of a head start. Still, brute forcing a 10 character password that uses the full ASCII printable character set looks like it'd require.. 9,500 years on a single high end GPU.

No idea what the current state of cracking is, but probably they used some rules based approach (like John the Ripper used to have) to massively reduce the search space.

Note that !@# is just shift-1, shift-2, shift-3. So not unlikely that it would appear in a rules based approach. The password is numbers, english word, keyboard-sequence.

Thanks for that explanation. Being accustomer to a UK keyboard layout this didn't occur to me (as shift 1-3 is !"£ here).

You have no idea how brute force md5 was like. You just look up a 80TB db table full of hash strings.


Are you saying JtR no longer has a rules-based approach, or that it's no longer used?

It's still actively maintained.


I'm saying I haven't tried to crack a password in about 12 years :)

Fair enough.

Unreal that he was able to crack it so fast.. a little scary really! He might have access to precomputed password hashes in a database. For example, you create a massive password list and compute all the hashes, save them in a database, why would you compute these hashes and throw away the results each time. You might just say "select plain_text from results where hash = '27934e96d90d06818674b98bec7230fa';". Just a guess though.

It's called a rainbow table, and it would be gigantic for 10 character strings with special characters considered.

Small size required (1-10 length, a-z, 0-9, Symbol 14 !@#$%^&*()-_+=) for a rainbow table needed for the hash would be around 438TB.

Am I doing the math wrong here? You have a 50 character space, and a 10 character password length. This gives you 50^10, roughly 9.77 * 10^16, permutations.

Even assuming you could store each possibility in a single byte, which you can't, that would still take about 86PB to store. Considering you would need to store both the key and the hash in order to have a useful table, it seems you would actually need to have a few exabytes dedicated to this.

Greenmountain's link below (and the Wikipedia page for Rainbow Table) cover it, but you do a space-for-speed tradeoff by basically re-hashing your hash repeatedly, and looking up if the result is in the table, which gives you a short-list of passwords from the pre-computed domain to try.

There is a diminishing-returns limit to how small your rainbow table can be before it starts getting both false positives and false negatives, and bigger password domain makes it worse, but they require less than 1 bit per covered password.

for MD5 GPU bruteforce would be practical and not require any storage. You can do hundreds of millions of trials per second per GPU without having to manage all that storage.

Can you provide explanation on how to compute that? Thanks.

Naively, I get 3 exabytes.

(50^10 + smaller terms) * 256 bits (SHA256 size) Number of hashes * size of hash to store.

Obviously this isn't how it's actually done. The best page I found describing the process is: http://www.freerainbowtables.com/en/faq/

The forum is fascinating: http://www.freerainbowtables.com/phpBB3/uncracked-hashes-f23...

It's probably just the number of permutations times the length of each hash.

No doubt the amount of data you would have to store for such a massive table would be glacial :-)

there are crackers that work with templates, so that they reduce the amount of space to search. the trick is to have good templates. for example, in this case, they probably had a template that was 3 digits, 4 lower-case letters, 3 symbols. the idea being that people are more likely to do that than 9#gag0e!0@, for example.

so it's a combination of luck, computing power (they probably have a farm of gpus), and careful selection of templates (probably guided by analysis of known passwords).

It's not just that template, it's an "obvious" 3 digit number, a 4 letter dictionary word, and "123" with shift held down. If you had some sort of statistical password ordering it wouldn't be that far down the list.

You mention "123" with the shift down and that in itself gives us a clue about it's possible origins. If the last part was shifted `123` on a UK keyboard then it would be `!"£`. So apart from USA layout keyboards, what other keyboard layouts country wise yeild a the same result from shifted 123. Still does not prove anything, but certainly is something to be mindful of. Either way I know I can sleep at night.

On the other hand, I know several Swedish programmers (here in Sweden) who do programming on a US keyboard. In part because it's more difficult to get the {}[], etc. keys with a Swedish keyboard. I suspect the same might be true with other nationalities.

I will exclude France and Germany if the (Shift-123) is different from French/German layout, but otherwise a lot of programmers (power users) use the US layout. Esp. if we are speaking about people of certain age who maybe have started when DOS was cool.

you're right. and just to clarify for others the crackers can try certain digits (or doubles) before others and include common patterns (like 123) and transformations (like holding shift down).

Kapersky cracked it. Symantic said brute force failed. That confused me for a second also.

I think they just googled the hash, see my post above.

Never over look the obvious, maybe he didn't crack the hash, maybe he just knew the password. Were you all born yesterday, where's the proof of concept here?

What better way for kaspersky to promote themselves?

The article neglects to mention what is perhaps the most important element of this story: the hashing algorithm used.

Cracking a hashed algorithm computed in SHA-512 or even BCrypt is a different story from MD5.

That has got to be one impossible rainbow table.

More likely they used a table of known existing passwords and variations on the them?

... maybe the FSB let them borrow one?

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact