DIRECT DOWNLOAD LINK FOR LEAKED MT. GOX ACCOUNT DATABASE (CSV FILE)

[F104]

on this site you can create your md5 hash if you are not sure which pw you used or just want to check if it is in there:

http://www.insidepro.com/hashes.php?lang=eng

newer hash starting with $1$:
enter password and salt. you will find your hash at "MD5(Unix)"

salt is between the second and the third $ character:
$1$/gKxns/A$42b18btDR4VVUJR8hOEqW0

hash goes after the third $ character:
$1$/gKxns/A$42b18btDR4VVUJR8hOEqW0

I am in not affiliated in any way with the site and can not tell if they are trustworthy. So only check if your password is weak or you have changed it everywhere else.

When the Gox problems first came up a few days ago I went in and changed my password. They have the *new* password. I have $4.65 in Gox and the new password is unique to Gox. It feels spooky but I guessed I dodged a bullet...unless the hoodlums have more info Gox isn't talking about.

Thanks for posting that link.

[1713995933]

1713995933

[1713995933]

1713995933

[1713995933]

1713995933

[1713995933]

1713995933

[F104]

It appears that someone who performs audits on our system and had read-only access to our database had their computer compromised. This allowed for someone to pull our database. The site was not compromised with a SQL injection as many are reporting, so in effect the site was not hacked.

No, you weren’t hacked, you employed people with as much responsibility, professionalism, and sense of duty as you: none.

It makes it OK that it was "someone else" and not you? Earlier you blamed each victimized user even as the complaints mounted.

Gox' character seems at the level of an immature 12 year old.

[bigfoot]

on this site you can create your md5 hash if you are not sure which pw you used or just want to check if it is in there:

http://www.insidepro.com/hashes.php?lang=eng

newer hash starting with $1$:
enter password and salt. you will find your hash at "MD5(Unix)"

salt is between the second and the third $ character:
$1$/gKxns/A$42b18btDR4VVUJR8hOEqW0

hash goes after the third $ character:
$1$/gKxns/A$42b18btDR4VVUJR8hOEqW0

I am in not affiliated in any way with the site and can not tell if they are trustworthy. So only check if your password is weak or you have changed it everywhere else.

When the Gox problems first came up a few days ago I went in and changed my password. They have the *new* password. I have $4.65 in Gox and the new password is unique to Gox. It feels spooky but I guessed I dodged a bullet...unless the hoodlums have more info Gox isn't talking about.

Thanks for posting that link.

The link was very helpful. Now I know what password that was stolen. It appears that this data was recent within the past few days because I changed my pass last week.

[F104]

I changed my password around 8:30PM USA west coast time June 16, so it was after that they got the data.

[bigfoot]

I changed my password around 8:30PM USA west coast time June 16, so it was after that they got the data.

That puts its between Sunday the 12th and 16th that the data was stolen.

[NO_SLAVE]

..... password hack - About 717 quattuorvigintillion years

paranoid - Yes

Just because they really are out to get you doesn't mean you aren't paranoid.

[andes]

I hope you guys are interested in buying Viagra and increasing the size of your penis.

Ha ha, yes, brace for spam impact! Especially watch out for Bitcoin email scams in the future. This email database guarantees a high percentage of obsessed people within a narrow theme. Any scammer would be delighted to receive such a valuable file CSV file.

[F104]

I changed my password around 8:30PM USA west coast time June 16, so it was after that they got the data.

http://blog.zorinaq.com/?e=55 says "...Contrary to previous claims from the MtGox owner, this indicates that many accounts had been compromised for at least days, if not weeks, before today's attack. This may explain some of the reports of Bitcoins being stolen from MtGox accounts in the previous days and weeks, as reported on the forums."

Something doesn't add up. My password on the posted .csv was created on the evening of June 16 west coast time. If blog.zorinaq.com is correct, then there were at least two separate seizures or losses of user lists from Gox, the first being long before Friday's release.

What am I missing? I am not the smartest rock in the forest.

[F104]

I changed my password around 8:30PM USA west coast time June 16, so it was after that they got the data.

That puts its between Sunday the 12th and 16th that the data was stolen.

It couldn't have been before the 16th because I made up the password in the .csv on the 16th.

In post #75 above we have a link to a hash generator. I checked my "before" and "after" passwords. The hash in the .csv represents my "after" password, i.e., I created it at 8:30PM USA west coast time on the 16th. The data loss could not have occurred before then, my new password didn't exist.

[Superform]

i woke up this morning to see my email account was taken over.. everyone on that list should assume the passwords have been compromised - i have since retaken over my account

[The Script]

i woke up this morning to see my email account was taken over.. everyone on that list should assume the passwords have been compromised - i have since retaken over my account

I think someone tried to get into mine, which may mean my hashed password on the list was cracked? Gmail reported "suspicious activity" when I logged in this evening. You can be sure that I changed my password and that this will be prompting me to take a closer look at ALL my computer security protocols and settings. Perhaps this is a good wake up for the community, up til now a lot of people have not taken their bitcoin security very seriously.

[makomk]

http://blog.zorinaq.com/?e=55 says "...Contrary to previous claims from the MtGox owner, this indicates that many accounts had been compromised for at least days, if not weeks, before today's attack. This may explain some of the reports of Bitcoins being stolen from MtGox accounts in the previous days and weeks, as reported on the forums."

Something doesn't add up. My password on the posted .csv was created on the evening of June 16 west coast time. If blog.zorinaq.com is correct, then there were at least two separate seizures or losses of user lists from Gox, the first being long before Friday's release.

Looks very much like there was some kind of ongoing compromise that caused the password list to be leaked on more than one occasion over a period of at least two days, yes. Probably more than that if we assume the attacker attempted to brute-force the passwords themselves before posting on that forum or offering them for sale.

[sandos]

Salts should include something unique for the site! Im not sure this is the case here, it would alleviate the problem with re-using password-hashes between many sites.

[gongcheng]

I couldn't believe it is real.

[kjj]

Salts should include something unique for the site! Im not sure this is the case here, it would alleviate the problem with re-using password-hashes between many sites.

Salts have been random for two months.  That's even better than being unique to the site.

[BubbleBoy]

The salt should have a random part per user stored in the database and a static part per site stored in some include file.
The first part prevents massive parallelization, rainbow tables etc.
The second part keeps the password secure when only the database is leaked (ex. a SQL injection that does not escalate to code execution). In the case of MtGox it wouldn't have helped since the read-only account probably had source access too.

Extending this idea, email can be stored using reversible encryption. Thus a simple database leak is not sufficient to compromise all emails, you need local access to the source.

[Karmicads]

Thout Shall NOT.... er...

Said Moses descending MtGox,

"I was lucky to escape in me jocks."

"Your bitcoins are gorne,"

"But the good news is porn..."

"...and Viagra spam's filling your inbox. "

[kjj]

The salt should have a random part per user stored in the database and a static part per site stored in some include file.
The first part prevents massive parallelization, rainbow tables etc.
The second part keeps the password secure when only the database is leaked (ex. a SQL injection that does not escalate to code execution). In the case of MtGox it wouldn't have helped since the read-only account probably had source access too.

Extending this idea, email can be stored using reversible encryption. Thus a simple database leak is not sufficient to compromise all emails, you need local access to the source.

If you think about it for a moment, I'm sure you will see that the static part is nearly useless.  The random part changes the game from "break once, break everywhere" to "break once, break here only".  That is huge.

But, if an attacker can brute force two passwords with static salt, they then know the static salt, and it offers no more protection.  The keyspace for the third attempt will have fallen back to the keyspace of the original password.  That is a mere speedbump compared to the brick wall of the random salt.

[BubbleBoy]

If you take the time to read my post carefully you will see I've acknowledged that the static part does not improve protection against brute force. It ensures that to even attempt brute force, the attacker must have read access to the source, not just the database. That's a different class of attack, a significant speed-bump for the attacker from a layered security perspective.


Edit:

But, if an attacker can brute force two passwords with static salt, they then know the static salt, and it offers no more protection

This seems to be the source of our quarrel. You seem to imply that the static salt can be inferred without reading the source. For a static salt that has enough entropy (128 bit), that should be impossible. Since this is selected once by the website owner, the condition is easy to meet. For example the MD5 and SHA1 based crypt algorithms can use a salt of any length.

[Raulo]

The salted crypt() hashes are more difficult to crack but so far I have found 2706 out of 59236 passwords of the database by just one hour GPU dictionary-based cracking.  It can be safe to assume that the attacker was able to crack similar number and could control thousands of accounts.