i suspect some people here don't really know in any detail how password cracking works.
you start with a dictionary. a good dictionary combines multiple passwords, slang, common patterns of keys on the keyboard, and old, known, passwords (so all the entries here will be added, for example).
but that's just the start. the cracking programs also have rules. in simple terms these can be "shift to upper case" or "combine two words from dictionary" or "reverse word" or "replace "e" with "3". and there are common sets of rules that people develop (and test) that do standard transformations like automatically making passwords "leet", or extending with common sequences (123), etc.
and you can automate this. so something like hashcat will generate random rules and apply them to the dictionary. because the rules are written so that they can be composed this is surprisingly powerful and probably explains some of the "harder" cracks on this list.
the only way to beat this, then, is to use random passwords (for example, as generated by keepass) and to make them large enough that just running through every combination doesn't work.
on size: what is important is the number of available combinations. systematic cracking - trying every possible combination - still uses common characters first so "size" is a combination of character variety and number of characters. again, something like keepass makes this easy.
finally, note that on some old or poorly maintained systems, you may be restricted (perhaps without knowing) to 8 characters. then using a wide range of characters is critical.
i know this is obvious to many, but some of the comments about "hard" passwords made me think it might be useful...
So this is not the complete set of passwords, only the ones that have been cracked so far, using a dictionary? Scanning through the list, very few look like a random set of characters that a password generator would come up with. Does that mean that passwords which were randomly generated are, and are likely to remain, safe?
I have a tangentially related question. During this LulzSec situation, I stepped into 2009 and started using LastPass. I generated 16 character random passwords for every place that I've been visiting. As I understand it, these passwords are encrypted on my machine and then uploaded to LastPass servers. When I login with my master password, I have access to all of these passwords unencrypted.
My question: is there an intrinsic weakness in storing these passwords at a central location? E.g. would it be feasible that LastPass gets targeted by a complicated blackhat attack, and then instead of losing just one of my passwords I lost them all? Or is the manner in which they are encrypted and transmitted secure enough to prevent this?
Correct me if I'm wrong: you mean that in the real world, salted passwords have only one advantage over plain text passwords, which is to buy you some time ? (albeit it's a strong advantage)
A few people seem to be commenting that the salt used for all of the passwords is the same.
This is not the case.
These are crypt(3) strings and the $1$ at the beginning signifies the hash scheme used, not the salt--$scheme$salt$hash. The 1 means that FreeBSD-MD5 is the algorithm used, which is basically MD5 with the salt iterated 1000 times.
Your comment that this is MD5 x 1000 is very informative and got me searching for the FreeBSD MD5 crypt function, and I found this gem from /usr/src/lib/libcrypt/crypt-md5.c:
/*
* and now, just to make sure things don't run too fast
* On a 60 Mhz Pentium this takes 34 msec, so you would
* need 30 seconds to build a 1000 entry dictionary...
*/
for(i = 0; i < 1000; i++) {
MD5Init(&ctx1);
if(i & 1)
MD5Update(&ctx1, (const u_char *)pw, strlen(pw));
...
... which seems to still be the default implementation in FreeBSD. I'd guess it's time to increase the iterations to 200000.
A lot of them are just 6 characters. Even a random 6 character password can be brute forced in a few minutes. Many of the short ones were just single dictionary words, so wouldn't even get past the initial check for stupid passwords--they would fall in seconds.
Most of the longer ones seem to be simply combinations of a couple dictionary words, or a word and a number, or similar fairly low entropy combinations that would come early in a brute forcer's search.
Most of the ones that aren't like that are based on simple patterns on the keyboard, which would also be in a brute forcer's list of things to check early.
On occasion when signing up for an account that I'm just testing out, I don't feel like creating a random password for it, so I just use a simple one. If it turns out I want to use the service, I will change it to a more complex one. This could be what happened here.
It's okay, Bitcoins don't have any potential monetary value!
If I were to sign up for MtGox, I don't know if I'd use anything above my standard "don't care" password, at least until I decided to get serious about it. Typing "shifty3rd" is easier than generating a LastPass password - and I only use it for accounts when I don't care if they're compromised.
I take it straight up dic attack, i see no gen password with 32 chars in it. Guess this teaches you a lesson, 32 character generated password (or max pass size) as a requirement for 99% of sites. Now if only windows had a standard password storage API which programs can access using special rules and special admin programs can manage this way just like the web browser we can have password stores for windows + sync to cloud.
KeePassX + Dropbox bro. It's only an alt-tab and a right-click -> log in to site on whatever you want to get into, once you enter your master password and/or present your password file.
What kind of impact would having used something like sha-512 with a 128 bit salt have had over md5? How many more cycles do those take to generate? I assume the attacker had to brute force the salt from a known password as well, if that's sufficiently random that should provide some security as well shouldn't it?
I'm pretty sure this article[1] is posted daily on HN. General purpose hashing functions are all fast (which, for a password storage system, is synonymous with bad).
Well, considering that 292 of the passwords contain mixed case, 79 of them are 12 characters or more (this one's nice: "qwe123QWE!@#"), 59 of them contain non-alphanumeric characters, and 6713 of the 8655 passwords posted are unique ... it's probably only a matter of time.
Nice. I think it's time to upgrade all my passwords.
Yeah mine niether. I have confidence it won't end up there either. The way the difficulty and time hockeysticks up once you hit the low hanging fruit is amazing(<8 char, non complex, simple patterns and common passwords, dictionary words and number / symbol variants). http://www.rakkhis.com/2011/06/i-was-hacked-mtgox-bitcoin-3-...
Couldnt find mine.. thats a comfort. =) Unfortunately most web based system ive encountered has 20char as most for key. My new passphrase model is based on 128 char key using two values piped through sha512. It works... but friendface probably wont accept it :)
Could someone help this newbie understand why proper salting doesn't make this hard enough? And how does the cracker know they have the right password? Wouldn't they need to check it against the authentication mechanism or figure out the algorithm?
If the crypto method being used is strong enough, then there is no need to obscure the authentication algorithm or the salted value. That just provides a little bit of security through obscurity, it doesn't actually harden the passwords anymore. Thus, modern password hashing libraries just put the algorithm and salt information in the password string itself, so that the string of data you store in the database contains 3 pieces of data: The algorithm used to hash the password, the salt, and the password hash. The benefit of this is convenience: Different platforms/languages can all create/authenticate various password hash types with ease as long as everybody sticks to this format.
And because of this, if you choose a weak crypto method to hash your passwords (which is what MtGox did), then an attacker conveniently has the 3 things they need to attempt to crack the password: The algorithm, the salt and the hashed value all in the same place.
However, if a strong crypto is used (IE a computationally intensive and slow hash), then the fact that the algorithm, salt and hashed value are in the same place doesn't really weaken the passwords. With an expensive enough hash, even if the attacker has all the information about how to crack the password right in front of them, actually performing the necessary computation would be so expensive that a brute force attack is effectively protected against.
You can see more details about the format of the password strings and where the 3 parts of data are stored here: http://php.net/manual/en/function.crypt.php
(the PHP page had the best explanation of my quick search, though this isn't just PHP specific)
The purpose of salting is to prevent the use of "rainbow tables" (precomputed hashes). With salted passwords, the attacker has to compute the password hash for every password he tries (takes time), he cannot use pre-computed hash tables and just compare the password hash to the precomputed hashes (a simple string compare).
Using one salt defeats rainbow tables. Using multiple salts does not defeat it any better.
Using multiple salts would seem to help defeat brute forcing or dictionary attacks, but that is only true if the salts are secret... the problem is that they are not secret because the at this point the attacker access to everything, including the salts.
[+] [-] andrewcooke|14 years ago|reply
you start with a dictionary. a good dictionary combines multiple passwords, slang, common patterns of keys on the keyboard, and old, known, passwords (so all the entries here will be added, for example).
but that's just the start. the cracking programs also have rules. in simple terms these can be "shift to upper case" or "combine two words from dictionary" or "reverse word" or "replace "e" with "3". and there are common sets of rules that people develop (and test) that do standard transformations like automatically making passwords "leet", or extending with common sequences (123), etc.
and you can automate this. so something like hashcat will generate random rules and apply them to the dictionary. because the rules are written so that they can be composed this is surprisingly powerful and probably explains some of the "harder" cracks on this list.
the only way to beat this, then, is to use random passwords (for example, as generated by keepass) and to make them large enough that just running through every combination doesn't work.
on size: what is important is the number of available combinations. systematic cracking - trying every possible combination - still uses common characters first so "size" is a combination of character variety and number of characters. again, something like keepass makes this easy.
finally, note that on some old or poorly maintained systems, you may be restricted (perhaps without knowing) to 8 characters. then using a wide range of characters is critical.
i know this is obvious to many, but some of the comments about "hard" passwords made me think it might be useful...
[+] [-] frederickcook|14 years ago|reply
[+] [-] brianleb|14 years ago|reply
My question: is there an intrinsic weakness in storing these passwords at a central location? E.g. would it be feasible that LastPass gets targeted by a complicated blackhat attack, and then instead of losing just one of my passwords I lost them all? Or is the manner in which they are encrypted and transmitted secure enough to prevent this?
Thanks.
[+] [-] loy22|14 years ago|reply
[+] [-] bitbear|14 years ago|reply
[+] [-] andrewcooke|14 years ago|reply
WTF. some fuckwit downvoted this? i wrote the text i am correcting. screw you. why do i bother to write useful comments? this place gets worse.
[+] [-] jake_morrison|14 years ago|reply
[+] [-] mukyu|14 years ago|reply
This is not the case.
These are crypt(3) strings and the $1$ at the beginning signifies the hash scheme used, not the salt--$scheme$salt$hash. The 1 means that FreeBSD-MD5 is the algorithm used, which is basically MD5 with the salt iterated 1000 times.
[+] [-] snorkel|14 years ago|reply
[+] [-] tzs|14 years ago|reply
Most of the longer ones seem to be simply combinations of a couple dictionary words, or a word and a number, or similar fairly low entropy combinations that would come early in a brute forcer's search.
Most of the ones that aren't like that are based on simple patterns on the keyboard, which would also be in a brute forcer's list of things to check early.
[+] [-] SeoxyS|14 years ago|reply
My password isn't on the list—it's a randomly generated 17-char string of alphanumeric and mixed case character.
Btw, you should all check out 1Password. Automates the process, syncs with all my devices and dropbox, and integrates with all the major browsers.
[+] [-] doogle88|14 years ago|reply
I always use unique passwords so I don't care that much if it gets broken.
[+] [-] AndyKelley|14 years ago|reply
[+] [-] dekz|14 years ago|reply
123456 -> 199 results. password -> 118 results.
Who would use such weak passwords for an account with potential monetary value?
[+] [-] BCM43|14 years ago|reply
[+] [-] pavel_lishin|14 years ago|reply
If I were to sign up for MtGox, I don't know if I'd use anything above my standard "don't care" password, at least until I decided to get serious about it. Typing "shifty3rd" is easier than generating a LastPass password - and I only use it for accounts when I don't care if they're compromised.
[+] [-] DougBTX|14 years ago|reply
[+] [-] pbreit|14 years ago|reply
[+] [-] flexd|14 years ago|reply
While I'm glad I do not have a account there they would not have been able to crack my password :-)
Edit:
I am a fool, salted hashes are probably not in anyones rainbow tables :)
[+] [-] cipherpunk|14 years ago|reply
[+] [-] getsat|14 years ago|reply
Not really a surprise considering they were hashed using one of the fastest/weakest common hashing algorithms.
[+] [-] dlikhten|14 years ago|reply
[+] [-] pavel_lishin|14 years ago|reply
[+] [-] seanp2k|14 years ago|reply
[+] [-] thadeus_venture|14 years ago|reply
[+] [-] getsat|14 years ago|reply
[1] http://codahale.com/how-to-safely-store-a-password/
[+] [-] meric|14 years ago|reply
[+] [-] thaumaturgy|14 years ago|reply
Nice. I think it's time to upgrade all my passwords.
[+] [-] rakkhi|14 years ago|reply
[+] [-] shawndumas|14 years ago|reply
[+] [-] moondistance|14 years ago|reply
[+] [-] seanp2k|14 years ago|reply
[+] [-] cel|14 years ago|reply
[+] [-] devinlane|14 years ago|reply
[+] [-] pavel_lishin|14 years ago|reply
[+] [-] forensic|14 years ago|reply
this list is just the low hanging fruit
[+] [-] pandrew|14 years ago|reply
[+] [-] pbreit|14 years ago|reply
[+] [-] birken|14 years ago|reply
And because of this, if you choose a weak crypto method to hash your passwords (which is what MtGox did), then an attacker conveniently has the 3 things they need to attempt to crack the password: The algorithm, the salt and the hashed value all in the same place.
However, if a strong crypto is used (IE a computationally intensive and slow hash), then the fact that the algorithm, salt and hashed value are in the same place doesn't really weaken the passwords. With an expensive enough hash, even if the attacker has all the information about how to crack the password right in front of them, actually performing the necessary computation would be so expensive that a brute force attack is effectively protected against.
You can see more details about the format of the password strings and where the 3 parts of data are stored here: http://php.net/manual/en/function.crypt.php (the PHP page had the best explanation of my quick search, though this isn't just PHP specific)
[+] [-] chmike|14 years ago|reply
[+] [-] riffraff|14 years ago|reply
[+] [-] DougBTX|14 years ago|reply
[+] [-] gvb|14 years ago|reply
Using one salt defeats rainbow tables. Using multiple salts does not defeat it any better.
Using multiple salts would seem to help defeat brute forcing or dictionary attacks, but that is only true if the salts are secret... the problem is that they are not secret because the at this point the attacker access to everything, including the salts.
http://en.wikipedia.org/wiki/Salt_%28cryptography%29
[+] [-] OoThah7o|14 years ago|reply
[+] [-] romland|14 years ago|reply
Why would you post this? If someone really wanted to pair them up, they could have but that at least would have taken -some- determination.
Obviously you knew you were pushing it since you even went out of your way to create a new handle. For the "lulz"? Troll.