People talk a lot of trash about frameworks like Rails, but I can spin up a shell application with bcrypt authentication via devise, roles-based authorization via cancan or declarative authorization, built-in CSRF protection, and better-than-decent default XSS protection in less than 30 minutes.
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.
It is not so much about MD5, but more about not using a random salt for each password.
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).
I have received the following email 6 times, edited to remove referral code and Bitcoin address:
"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/
Sincerely,
A Bitcoin supporter
1XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX7"
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.
Just got this too. Fortunately, I use different passwords for everything. But a lot of people don't. I was able to find 520 occurrences of the "password" MD5 in a search in the leaked database so far. Still searching.
Are you sure it's salted? $1$ just seems to indicate that phpcrypt used a MD5 digest. If I were you I would do an MD5 digest of your password and compare it to see if it was actually salted. Considering it's MD5 and your account may potentially have monetary value, I wouldn't be hesitating to be changing all accounts using that password.
The G means Giga, as in 4.5 Billion? I haven't seen it used that way before.
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?
13 characters is good. Letters, numbers, and punctuation is good. But note that "abigp4ssword!" qualifies under your rule. Any dictionary terms even with l33tspeak encoding will weaken it.
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.
I bought some bitcoins on MtGox a month or so ago. My email address was among those in the leaked database. I received a message from MtGox about the security breach, and shortly thereafter from an anonymous user hoping to profit:
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 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
Perhaps 100% unrelated, but for the first time since its launch I just got a 'suspicious activity' notice when I tried to log onto my Google Accounts/Gmail within the past hour. I got in ok and changed my password drastically, however one of the first emails I got of course was one from MtGox letting me know about this. Probably unconnected, but I could imagine them trying to take a hit on a lot of registered Gmail accounts after they got the information. I only signed up for an MtGox account, but I've never traded with it or really used Bitcoin.
All gmail addresses in the leaked file (including mine) got this notice. It's just a precaution from google.
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.
Hmm, figuring this is just likely (hopefully?) my iPhone or something, but my gmail shows an account login using IMAP from United States (MI) (198.228.226.x) about an hour ago. I've never been to that state.
EDIT: Nevermind, my have been my phone or something, because MaxMind is showing that IP as Ohio (where I am).
I have to admit that when you have real money behind a hobby[1] project of this size and amount you might want to hire some security professionals to do an audit of your system. It goes for all the exchanges. Heck, I hope brick and mortar banks do a 'real' audit while I'm on the subject (with all the hacking being done everywhere).
The title of an article I read recently comes to mind, "You don't know the problem." That is, creating an un-hackable system isn't the problem.
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.
Ehm, how we you know that? Maybe the salts were stored another place? Or simply the attacker didn't release them? Or maybe MtGox used a site-wide salt that's stored in their codebase somewhere?
Passwords seem to be hashed. I think this is to be expected since this is such a techy thing (currency?), but still nice to know. Now whether they are hashed and whether the algorithm used is safe are a different story.
There are 1766 hashes that are 32 characters in base-16 (probably MD5, possibly with a site-wide salt) and 59245 hashes that are 34 characters in base-66 (appears to be an MD5-based crypt(3) hash).
There are duplicate hashes. Taking out the dups, there are 1610 md5 hashes. And 34% of these are crackable with a rainbow table. This means they are unsalted.
Yes, although some of them (especially for older accounts, which probably haven't been logged into in a while) appear to be unsalted MD5. That's not unusual: it probably means that MtGox used unsalted MD5 at some point in the past and was upgrading people's passwords in-place after a successful login.
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. [3] 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."
... and considering the audience and the amount of free GPU hardware out there, it's not out of the question that someone might try and turn all that parallel computing muscle toward more nefarious purposes. Not that this all seems necessary, of course, given the woefully insecure state of MtGox these days...
The crypt'ed MD5 hashes have a special prefix which indicates that's what they are.
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).
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').
Attempting to hide it somewhere else doesn't really help when your whole system is compromised. Salting+hashing isn't the answer to 'how to store passwords so no hacker can ever get them', it's the answer to 'how to store passwords so it would take a very very long time and a lot of resources for a hacker to ever get them'. It's designed like this to also allow easy authentication of users by simply performing the same process used originally. So the only real thing storing the salt somewhere else would accomplish is greater latency for authentication.
I believe the standard library for bcrypt in ruby also uses salts, it just stores the salt with the hashed password data.
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.
Bcrypt uses salts. But your link is correct, attempting to roll your own crypto is getting all these companies caught out and bad crypto use is causing their users to suffer. I for one would now not feel safe using a password for more than one website.
I can't login at MtGox at the moment. What's the best measure to take now?
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?
I wonder - if you have a payout BitCoin address configured in MtGox, you should somehow be able to prove that it is your address? Not sure - but might be a good idea to investigate that?
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?
You would be surprised how few developers know about bcrypt. I didn't learn about it till the Gawker attacks and all of the amazing threads by the tptacek and the other crypto guys that wouldn't stop saying "use bcrypt!*.
Bcrypt is nice but anyone attempting to kid themselves that they're creating secure webapps should at least know security standards like PBKDF2. It's in practically every good crypto library, as well.
I've got people in IRC telling me that MD5+rot13 is good enough, or to just use some SHA implementation. This was after I'd already espoused how trivial bcrypt was.
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.
Hm, I'd like to know more about why MD5+rot13 is good enough and also why they justify "good enough" over what could be argued as a "good" or perhaps very good solution, e.g. bcrypt?
The only thing MD5+rot13 would have going for it is that you couldn't just trivially google the hashes to get the reversal (as is the case in a disturbing number of cases). Of course this only lasts as long as they don't figure out that it's MD5+rot13.. I'd give that about 5 minutes tops.
I deleted my reply (where I stated that the passwords were salted).
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.
If you guys do work on this, send me an email (email is in the profile).
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.)
For sufficiently fungible products, the "Market Maker as Exchange" model works really well. What you'd basically have is high spreads for retail investors, and lower spreads for institutional investors. So your consumer-facing company would make a spread and then flatten its exposure by trading with other market-makers.
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.
"Is there even a way to make a server unhackable? I am really not sure :-("
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.
Anything can be hacked if it has information on it. There's even those terrifying "cold hacks" where you yank the memory stick from a machine that's powered off, chill it to preserve lifespan, and plug it into another machine to read it, the thing coughing up the contents like some zombie.
Nothing can ever be fully secure, but you can make it secure for all practical considerations.
It's definitely not impossible to prevent issues like this, it just requires effort.
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.
Uh, seeing as this was an SQL injection vulnerability, just using GAE wouldn't protect against that at all.
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.
I am not that worried about writing a web application properly. But I am just an amateur when it comes to administrating a server. I would be more worried about some security hole in some random service that is running on the server by default, that I never even heard about.
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...
"I am not that worried about writing a web application properly.... I would be more worried about some security hole in some random service that is running on the server by default, that I never even heard about."
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.
Well, I just spent two hours talking to the people interviewing developers at mt.gox and tradehill.
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.
As a note, a user named <TD> has join #bitcoin-dev purporting to be from Google. They are restricting access to compromised accounts and sending out texts to change passwords. They stared with plaintext-passworded users but it appears it will include everyone. I don't know the legitimacy of these claims, but based on some of the comments here and in #bitcoin, it appears to be quite legitimate.
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.
I can confirm this. My email is in the leaked db. Both my mtgox and gmail passwords are unique, hard to guess by a dictionary attack and not shared with anything else. I received Google's message to change my password.
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.
I just got this notice. Glad to see Google being proactive here. I was a little worried when my application-specific passwords stopped working--but relieved when I saw it was Google.
I agree it is nice they are being proactive, however it would have been nice if they gave a little more detail to clarify this was merely proactive, not specific odd activity.
Reason: Most .NET/PHP-programmers just don't care about readable code nor security per definition; it's strongly bound to the reason they picked this language from the start.
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.