

MtGox salted passwords cracked - rakkhi
http://pastebin.com/NDm7XihA

======
andrewcooke
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...

~~~
brianleb
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?

Thanks.

~~~
shinratdr
Yes, it is. Use 1Password or KeePass because they aren't centrally hosted.
1Password even provides a little security through obscurity by using DropBox
for its optional keychain syncing. People store a lot of uninteresting crap on
Dropbox, filtering through to gather .agilekeychains would be a real PITA.

~~~
bluesnowmonkey
If only there were a device that could automate computational tasks, such
filtering would no longer pose a challenge. Some sort of compute-er...

~~~
shinratdr
If it was simple as filtering for those files, you would have a point. It's
not though. If you can't see the difference between a big compiled database of
1 million+ users password DBs vs a multiple petabyte mess of all types of
files including a handful of agilekeychains, then it's not worth discussing
further.

------
jake_morrison
So the entire user community is people with lots of hardware resources waiting
to brute force passwords. What could possibly go wrong? :-)

------
mukyu
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.

~~~
snorkel
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.

~~~
arundelo
Ease of increasing how long it takes to compute the hash is the main idea
behind bcrypt: <http://codahale.com/how-to-safely-store-a-password/>

~~~
benatkin
Yeah, it's pretty easy to change this in Devise, a popular auth library for
rails that uses bcrypt by default, and to have a custom value to speed up unit
tests: [https://github.com/plataformatec/devise/wiki/Speed-up-
your-u...](https://github.com/plataformatec/devise/wiki/Speed-up-your-unit-
tests)

config.stretches = Rails.env.test? ? 1 : 10

------
tzs
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.

------
SeoxyS
This is a brute force / dictionary attack. Only "bad" passwords have been
cracked.

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.

~~~
AndyKelley
It looks windows-only. Not going to work for me.

~~~
bradleyland
<http://agilebits.com/products/1Password>

Mac is the first platform listed.

~~~
seanp2k
Looks great but no Linux support. Since I use Ubuntu on my work (and home)
laptop and netbook, this is largely useless for me.

KeePassX + Dropbox is a great way to go, but it's kind of more "DIY"-ish.
Still not hard to set up, keeps all my passwords in sync, and KeePassX has
some great features like "auto-type" which basically is a one-click website
login.

I now use the max-length passwords on all the sites I use, and they're all
crazy random ones. I don't memorize any of them because it's so easy to reset
a password if I lost my KeePassX access (unlikely since it's on Dropbox + 4
computers + CrashPlan backups).

------
dekz
Hot damn some people have horrible passwords:

123456 -> 199 results. password -> 118 results.

Who would use such weak passwords for an account with potential monetary
value?

~~~
BCM43
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.

------
flexd
What you mean is that the ridiculously easy passwords have been cracked? Not
really a surprise considering they have been out for so long.

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
Rainbow tables do not exist for randomised salts.

~~~
meric
But if the salt is global and its value is "1", it might.

~~~
rmccue
The $1$ part of the hash is purely to indicate that MD5 was the encryption
algorithm used. The salt used is the first 12 characters, so from "$1$" to the
next "$"

For example, for "$1$JVf3ep..$uvo634QwxDsAuHMOZlKws1:riprip" the salt is
"$1$JVf3ep..$" (although those periods may just be padding, IIRC).

~~~
meric
Ahh. I misunderstood. Thanks.

------
dlikhten
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.

~~~
pavel_lishin
Does Windows not have something equivalent to OS X's keychain?

~~~
rprasad
Windows does have a password keychain (and has since XP), but AFAIK the only
programs that use it are Microsoft programs. Internet Explorer uses the
Windows keychain to store saved passwords.

------
thadeus_venture
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?

~~~
getsat
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_ ).

[1] <http://codahale.com/how-to-safely-store-a-password/>

------
meric
Hmm it isn't complete; My password isn't on there yet. =\

~~~
thaumaturgy
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.

~~~
doublec
"qwe123QWE!@#" is only nice until you look at the keyboard. First three qwerty
letters. First three keys just above them. Then the same shifted.

~~~
silencio
I was surprised at how few randomly generated passwords there were in that
list, if any. Like you mention, there's a lot of variants on
qwerty/12345/!@#$%: 1qaz2wsx, Zaq1Xsw2, 1qazxsw23e, 1q2w3e, !@#$1234, etc.

"ZXasqw12!@" was about as random as it got from a quick scroll-through, and
even that is basically just keys directly next to each other.

I assume randomness doesn't mean as much as sheer password length does when it
comes to crackability, but I wonder if there's anything to be learned from
this. Maybe only that random password generators tend to default to a safer
(longer) length? :)

~~~
DarkShikari
Random passwords are probably not going to be cracked by a run-through of John
with a ruleset, which is likely similar to -- or exactly -- what was used to
create this list.

These are salted FreeBSD MD5s (iterated hash); even with a powerful GPU,
you're probably only going to be able to check a few hundred thousand per
second at best.

------
moondistance
Anyone have a bitcoin exchange recommendation?

~~~
seanp2k
Tradehill is the new MtGox. They even copied the site design pretty much
exactly.

------
cel
My password isn't on that list, but it's on a different list. I found it by
googling my email address. :/

~~~
pavel_lishin
I wonder how many people google their password to check if it's been cracked.

~~~
seanp2k
Yeah dude, mine was on the bigger list. It's a 10chr semi-random password (all
lower case tho).

I pick passwords based on easy things to type and the memorize the pattern /
commit it to muscle memory. I also try to use obscure but pronounceable
patterns somewhere in the pass.

------
forensic
neither of my accounts are in the list, because i used long random passwords

this list is just the low hanging fruit

------
pandrew
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 :)

------
pbreit
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?

~~~
birken
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)

------
chmike
What about public-private key authentication ? Isn't this demonstration enough
?

------
riffraff
the salt seems to be the same for all of the password. Not exactly useful this
way, is it?

~~~
gvb
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.

<http://en.wikipedia.org/wiki/Salt_%28cryptography%29>

~~~
sorbits
I accidentally up-voted parent, so felt I had to reply since this part is
somewhat wrong:

> _Using multiple salts would seem to help defeat brute forcing or dictionary
> attacks, but that is only true if the salts are secret_

If I have a dictionary of common passwords, I need to hash this with the salt
used by MtGox and then I can test the hashes against _all_ the passwords from
MtGox.

Had they used a different salt for each password, my work would be _n_ times
as expensive ( _n_ being the number of passwords to test against).

~~~
gvb
Using multiple salts makes it more expensive, but it doesn't _defeat_ an
attack unless it makes the attack impossibly expensive. My contention is is
that multiple salts _by themselves_ will not make the attack impossibly
expensive.

Better encryption, e.g. bcrypt <http://en.wikipedia.org/wiki/Bcrypt> attempts
to make it impossibly expensive to crack passwords. Part of their technique is
to use per-password salts to increase the time for _all_ passwords, but the
key is to have an encryption algorithm that takes an "impossibly" long time
_per password_ as well. Key is that it is "an adaptive hash: over time it can
be made slower and slower so it remains resistant to specific brute-force
search attacks against the hash and the salt."

Rainbow tables are O(1). Salts are O(n). Bcrypt is O(big), where "big" can be
increased to keep it bigger than a "practical" attack will be willing to
attempt.

~~~
DennisP
Given that the bitcoin protocol adjusts the difficulty of block generation,
it's kinda ironic that mtgox didn't use bcrypt.

------
OoThah7o
Here are the plain text passwords combined with their respective mail
addresses: <http://pastebin.com/RhheV8Gj>

~~~
romland
I guess you can argue that no more harm can be done to the poor users of Mt.
Gox but I disagree.

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.

~~~
leon_
some determination? it's one invocation of john to pair them up.

releasing the cracked passwords at first was stupid and doesn't show any
skill. it only shows that you have a strong cpu.

~~~
getsat
> cpu

Consumer-grade GPUs are better at this than even the highest end CPUs.

~~~
leon_
no shit?!

