Granted, it's not perfect security-wise, but it beats the crap out of whatever mish-mash leads to this meltdown...or the one Citi had...or the one Sony had...or other one...etc.
I think security is one of the few areas where convention over configuration pays off by sidestepping lazy/sloppy approaches.
There should be capital punishment in software development for things like that.
Stronger hash algorithms such as SHA-1 suffer exactly the same issues when used improperly (i.e. when stored without salt, or data is exchanged without HMAC).
"Dear Sir or Madam,
A few hours ago the Bitcoin trading website Mt Gox has been hacked. Malicious individuals have been able to obtain a database containing usernames, email address and encrypted passwords. This information has been posted publicly on the internet.
As a Bitcoin supporter I'm now sending a message to every email address contained in the hacked database. This is to warn you that your username, email address and password have been leaked. I therefore strongly advice you to change your passwords. If you have used the same password on different websites it's highly recommended to change your password on all of your accounts!
For a more secure alternative to Mt Gox, the community appears to be moving to TradeHill. So this is no reason to lose faith in Bitcoin itself. It must be seen as a warning that not every website can be trusted with your data however! Their link is http://www.tradehill.com/?r=XXXXXXX (Note: You can remove the Referral Code when registering if you want!) This is certainly not the only website where you can exchange Bitcoins, also check out http://www.thebitcoinlist.com/dp_bitcoin/bitcoin-exchange/
A Bitcoin supporter
If the sender is reading this, your script works (too well), and the warning was received 2 1/2 hours after the one from Mt. Gox, so you probably should have saved yourself the trouble.
The From headers shows the email is sent from Bitcoin@unknown.com. However, digging into the headers it is actually coming from gXXXXXXX@bXXXXXXXXXX.gXXXXXXXXXXXXX.com (trying to give the guy some privacy, since he's trying to be helpful, but this way others who get the message can correlate it).
a) Every user of MtGox already received a message from MtGox directly telling them about the breach. His message did not add any new information at all.
b) He advertises for two direct competitor to MtGox, in once ase using what I assume is a referral link where he earns a comission for each trade.
c) He solicits donations for himself.
d) He does not give out his name and uses an invalid return address to hide his motifs.
e) He sent the message 6 times.
"If you were using the same password on Mt.Gox and other places (email, etc),
you should change this password as soon as possible."
"While the password is encrypted, it is possible to bruteforce most passwords
with time, and it is likely bad people are working on this right now."
Son of a...
I have a 13 character password with letters, numbers and punctuation. I also seem to have one of the salted ($1$) passwords.
How much in trouble am I really?
The article is 2 years old. There are botnets that I presume could do ~50 billion/sec now (Number pulled out of ass).
I believe bots are unlikely to have four high-end cards though, due to my assumption that the nature of bots come from weak users therefore weak computers.
Do you have a source for the capability of particular capacities to find passwords including botnets like my link?
The salt is the part after the $1$ before the next $. If that's more than a few chars you should be safe until you can change it to something completely different immediately, and don't use it anywhere else.
Dear Sir or Madam,
For a more secure alternative to Mt Gox, the community appears to be moving to TradeHill. So this is no reason to lose faith in Bitcoin itself. It must be seen as a warning that not every website can be trusted with your data however! Their link is removed (Note: You can remove the Referral Code when registering if you want!) This is certainly not the only website where you can exchange Bitcoins, also check out removed
A Bitcoin supporter
(bitcoin address removed)
I'm a bit annoyed that they didn't just sign me out and suggest a password change rather than force it (since I already use their 2-step authentication scheme and use different passwords for everything). On the other hand I'm happy to know that Google cares so much about the security of my account.
EDIT: Nevermind, my have been my phone or something, because MaxMind is showing that IP as Ohio (where I am).
It's probably unrealistic to expect that anyone will ever create a completely un-hackable system. Rather, one should design their systems to fail gracefully under attack.
If someone breaks in to my Citibank account, it doesn't much matter to me, because the banks have the authority to roll back transactions with the push of a button. Their power to do so is the greatest layer of security in the whole system; just as we have seen with Mt Gox.
Unfortunately, Mt Gox is not bitcoin, it's simply an exchange, so it's once removed from bitcoin itself. The owner of that account still lost $1000, and no one can reverse it. Contrast that with bitcoin, and you can begin to see the problem.
This is a fundamental issue with all currencies, not just bitcoin. It's a trade-off. When you hold currency, you hold responsibility for securing it. If I kept $500k in USD (paper currency, bonds, whatever) under my mattress, I'd have no recourse if someone broke in to my house and stole it. That is why I'm ok with keeping my money in a bank. I give up a lot for it, but I gain a lot of security.
EDIT: Okay, they appear to be unsalted (according to nbpoole): http://news.ycombinator.com/item?id=2671714
Edit: the email was longer than I expected and formatting messed up a bit on HN so here's a pastebin link: http://pastebin.com/H5bgDYhC
Edit: Just Google for the URL to find the respective Rapidshare link.
EDIT: Ops, I missed some hashes.
It's worth noting that crypt-ed MD5 (which appears to be what's in use here) is fairly weak on modern hardware when compared to an alternative like BCrypt. There's some basic information available on Wikipedia: http://en.wikipedia.org/w/index.php?title=Crypt_%28Unix%29...
" Graphics processors can speed up password cracking by a factor of 50 to 100 over general purpose computers. As of 2011, commercial products are available that claim the ability to test up to 2,800,000,000 passwords a second on a standard desktop computer using a high-end graphics processor.  Such a device can crack a 10 letter single-case password in one day. Note that the work can be distributed over many computers for an additional speedup proportional to the number of available computers with comparable GPUs."
For the other hashes, the fact that there's no nonce or other value stored alongside them was a strong hint (although it doesn't rule out a site-wide nonce). However, I confirmed my suspicion by Googling one of the hashes: it was on a list of unsalted hashes that had been brute forced (unrelated to this, the password was fairly common).
CRYPT_MD5 - MD5 hashing with a twelve character salt starting with $1$
So the hashes you see beginning with $1$ are probably salted.
The $1 is for MD5, the salt includes that $1 and the last $, so to crypt the text in php you do crypt($password, '$1$salt$'). Use single quotes to prevent $ from turning into variables. $password in this case (according to mtgox) was md5('password string').
[Edit: I meant your typical web application mucking about with salts, not their use within properly thought out things like bcrypt]
Salts will prevent the typical rainbow table attack where you have precomputed hashes for a large number of attempts. Salts won't prevent brute force, but bcrypt will make it so that brute force takes too long for a single given user.
I'm assuming MtGox will reset the passwords for those with an email account associated. Not sure what they will do for those without, hopefully they have IP logs for those accounts?
This is absurd. Anyone with a clue about anything knows better than to use unsalted MD5 or better yet, can imagine better ways to partition security for a system to prevent this, and at the very least can implement measures to prevent mass withdrawl without having to revert to transactional rollback after the fact.
Really sad. Was MtGox first? Why did they have so much volume anyway?
Edit: And perhaps a good chance to use bcrypt over say MD5 or SHA256. I'm surprised bcrypt wasn't the go-to implementation.
Seriously, there are people in here that don't understand the difference between encryption and hashing, don't understand the benefit of salts, think that there (is/should be) one "secure" salt.
The load of just absolutely false security information in here is startling.
Apparently the database has a mix of hashing strategies. It started with unsalted MD5 and was improved over time. The format of the PHP crypt output allows you to distinguish between hash types.
1) Stronger logical security
2) A triggering mechanism for halting suspicious trading
3) Clear rules for halting and rolling back market activity
4) Some measure of coverage for trading loss
I'm no expert in equity markets, but I would imagine someone who is can weigh in on how these specific issues are handled.
Halting is not the right way to run an exchange, because it creates "air pockets" of liquidity given sufficiently sophisticated traders. This is what lead to the "flash crash" last year: high-frequency traders didn't want to be caught with illiquid positions in the event of a halt, so they sold as quickly as they could, making a halt more likely. It creates a situation quite similar to a bank run.
(Instead, you might want the people who organize the exchange to also do some market-making, and to stabilize prices in order to grow volume, leading to a more profitable business overall.)
This gives the "Exchange" more flexibility than Mt. Gox has. It can offer more competitive prices when it's worthwhile, and pull back if trading with retail customers gives it too much net exposure. That's better than having a fixed fee for matching people with market-makers.
This is a rough approximation of how forex works.
I would try to put the whole thing on Google App Engine, at least then the burden would be on Google for the most part :-/
Its a pretty difficult thing, the simple answer it turn it off :-) however you're second comment is more relevant.
"I would try to put the whole thing on Google App Engine, at least then the burden would be on Google for the most part :-/"
Google does a good job of securing their servers, however the risk is not that the 'server' gets hacked, rather its the application running on the server. So for example someone can't log into your server but they can SQL inject a command to dump your web site's password list and they don't have to log in.
Good secure design would start with really really strong testing around the applications 'mutation' points (which is to say where it changes in response to user input). When I was at Google products had to go through a security audit before being released and those guys were pretty good at their jobs. This is one of those cases where seeing a lot of ways people try to attack services gives you a leg up on looking for common weak points.
Nothing can ever be fully secure, but you can make it secure for all practical considerations.
Securing a network/host/application is like getting (and staying) in shape. It's a process that requires an ongoing effort. There's nothing you can buy that will take care of it forever.
Most breaches aren't the result of "impossible to prevent" attacks, they're the result of basic due diligence not being followed. You're right though, that it seems some days like that's the rule and not the exception.
While you can't have an "unhackable" site (or an "uncrackable" safe), it's all a matter of risk vs. reward. You can certainly ensure that your site doesn't have any vulnerabilities listed in the OWASP Top 10 (and test it repeatedly over time to make sure it stays that way).
And that's not even getting into a more mature vulnerability management process that involves outside assessments, source code reviews, and threat modeling. All those things are also nice to haves (or may be required, depending on your industry and the type of data you have access to).
It's totally understandable to be a pessimist about the state of security in our industry, but preventing these types of issues is not a Sisyphean task.
An unhackable server is probably possible, but a non-trivial unhackable server probably isn't. But you can still create sites that are secure, even if hackable. If the hackers had accessed a database of bcrypted passwords and if the site would have locked down when it detected erroneous volume of transactions, there would be no headliner here.
GAE doesn't even use SQL, btw. At least last time I checked they didn't - they seem to be planning to support it in the future, though.
However, even if the server is secure, I suppose if it was known that I am the admin of a BitCoin bank, my home computer would become a target, too. If my home computer would be hacked and I logged into the server, I would be screwed, too. It just seems too risky...
While the latter can happen and is broadly easier for a script kiddie, believe me, the former is nontrivial and very rarely done correctly. Your average web app is full of vulnerabilities, and while scanning can't quite be fully automated it's definitely something you can use automation to help with, so don't think you're secure-through-obscurity.
You can still directly append unescaped user input to your query and execute that against your datastore, though the limited capabilities of GQL does limit the attack surface somewhat.
Tradehill: SHA-1 currently, looking at SHA-512. No one certified on security. Top creds repeatedly touted was one guy that developed "300 iPhone apps".
Mt.Gox: Was NOT hacked. There financial auditor had read-only access to the database and his computer was compromised. They were asked why the financial auditor had access to the data, with no response.
I was literally yelling about bcrypt, and apparently Mark (mt.gox) said that bcrypt wasn't actually very secure and that they're were going to use (1000 passes) of SHA-512.
You can't just secure the servers; you've got to secure the entire set of machines which ever connect to the servers, and all of the machines which ever touch the offline data. If your data is stolen off of a laptop or USB drive -- as an absurd amount of data has been -- it's just as stolen as if it's taken from the central server.
Can anybody help?
I filled out one of google's forms but I'm afraid it'll just be bot-processed :[
Edit: Here's what happened:
I got reports that my gmail account had suspicious activity so I had to reset my password. Unfortunately I already had a different password, and when I reset it, I changed it to the one that was hacked (I didn't know it was hacked yet). So google, trying to be awesome, made me change my password, and now I can't get into my account... I'm kicking myself so hard right now.
My gmail account's got six years of my life in it... whoever's got it has every tiny detail about me... and it's terrifying.
As an aside, seeing the public text file containing 60k mtgox accounts is strange. Without looking too hard I found a couple of people I know in there.
Good thing that password was unique and not shared with other accounts.
...or to quote the creator of PHP: http://axonflux.com/5-quotes-by-the-creator-of-php-rasmus-le...
Is this any different from RoR or Django, though?