If I had any bitcoins hosted on mtgox and, for some reason, had not already taken them out, I would do so right now. When you give them your bitcoins, you are trusting them to keep your money safe. I trust my money with my large bank for two reasons: (1) they have a large safe and have practice keeping people out, but more importantly, (2) if someone were to break in and take some of the bank's money, I would know that I could still withdraw my money because they have enough cash on hand for me to do so.
Mtgox has neither of those assurances.
They have absolutely no credibility on the security front. They were using MD5 with no salts at one point in time. They then moved to MD5 with salts. Now they are at "SHA-512 multi-iteration, triple salted." That seems more like they're trying to say "Oooohh! Look at us! See?! We're being secure!" Triple salted means what, exactly? (Other than the fact that it makes it clear these are people who read about salting online and then though "more is better.")
Next: "we have actively been patching holes." Oh no. You mean, you're just going through the code and looking for bugs and hoping you get them all? That might work for normal programs just fine, but even ONE vulnerability is enough to take an entire database. A database hosting just passwords may not be all that bad (it usually is, but it doesn't have to be). A database which hosts thousands and thousands of dollars? Now that is something to worry about. It truly does look like they got lucky on this attack.
As for the guarantee that banks give -- that if they get broken in to, I will still have my money -- there is no way mtgox provides this. Anyone who still has money on mtgox is asking for trouble.
I thought we were talking within the context of "serious problems". As for greece, well..it happened to Washington Mutual in 2008 - the largest savings in loan institution in the US. Of course, this is only one of many US banks which were not able to produce money when it was wanted in 2008.
There's a reason banks have a legal right to refuse a withdrawal, specifically because they may not have enough funds. That reason is: because it has and will happen.
There are stories (see consumerist.com) of cash withdrawals not being possible.
I admit I got a little off track though. My parent specifically stated withdraw money when he wants. There's plenty of evidence that at the peak of the crisis, some people had problems. But I agree, it seemed to have been few, and in the context of Mt Gox, it isn't really relevant.
I don't know of a single person unable to withdraw their money from WaMu as it went under. All of WaMu's accounts were then passed on to chase, and chase honord them. If WaMu went under, the savings accounts would have been FDIC insured. None of that will happen if Mt Gox is compromised in some catastrophic way.
Why in the world should a single branch be expected to hold that kind of cash for withdrawn without notice? There is a* huge* difference between "having the money" and "having the money in cash form on location".
If they barely had 10k in their vault, then it logically follows that they almost never need that much (otherwise they would obviously make it a point to keep more). If they rarely need that much, then it logically follows that somewhere at or less than 10k is a reasonable amount to have. There is no sense in taking the increased liability of having more if they don't need to.
Furthermore, acting as a "proper bank" means they do a lot more than just acting as your personal piggy-bank/mattress. If they have all their money tied up in cash, it means they can't actually be preforming real bank activities (investment).
I understand that. I am curious how effective insurance deposite works in the face of a country-wide breakdown. I know Greece has a deposit fund, I'm curious to see how effective it'll be (does it actually cover 100% of the deposited money (up to the maxium per account)?)
It doesn't. The FDIC doesn't have a fraction of the money needed to insure a fraction of the money that is supposedly FDIC-insured. More over, the United States likely lacks the gold to back our current currency, let alone the currency needed to prop up those who lose money in the situation of the decreasing number of banks failing.
Of course it does - the strength of the US economy.
The US economy may be fucked up in many ways, and may face some harsh transitions if it can no longer rely on the strength of the dollar as an international currency, but it is still a large economy. The loss of that strength will not magically result in the dollar having "no backing".
Certainly, if the dollar was replaced by the RMB internationally, the dollar would start to drop against other currencies - until it reached a realistic equilibrium point.
Pretty much every useful currency these days is "backed" by absolutely not one single atom of metal.
Which, it turns out, works just fine -- the belief that gold has value is roughly as magical as the belief that saying some words can turn wine into blood (and a prime sign of religious dogma in both cases).
The problem is that in ditching gold they went straight to faith-based currency. Even if gold was ugly and useless it'd still be a better base for currency than nothing because of its scarcity. It's too easy to create more money. We don't even print it anymore.
Yes, of course, and everybody knows that. The gold standard was abandoned across the world in the 20th century because it's unsustainable and inflexible. Please stop promoting this conspiracy-theory nonsense.
The "conspiracy" theory goes that this gold has either been loaned (that's why Ron Paul phrased his question to also check if they're "obligated") or sold to drive down gold price thereby making dollars are more attractive investment than gold. Hence the call for an audit. The "conspiracy" theory further suggests that all the world's central banks are doing this.
The FDIC doesn't have a fraction of the money needed to insure a fraction of the money...
Sure it does. The FDIC makes an annual assessment on financial institutions ranging from 2.5 to 45 basis points to keep the insurance fund solvent. In 2009 there were many special assessments to replenish the fund.
Insurance is always leveraged. Those skilled in the art are actuaries.
OK we are taking about vastly different scales here, but there is no absolutely trusted scheme in the world. The US has been printing money since 2008 to cover the losses of the Crisis, so the real world has an advantage here.
The reason Mt Gox needs to obsess over password database is because they don't seem experienced enough to secure the rest of their site. When it comes down to it, they are still a "PHP+mysql" site like all the others on the Internet.
Would you store your funds at the Bank of Wordpress?
There's nothing inherently wrong about using the PHP language or the MySQL RDBMS to build a secure website. Most of the terrible code on the internet is in PHP/MySQL, and most of the PHP/MySQL code is terrible—but that is not a deficiency of the language, but rather a consequence of its ease of use and popularity.
That, though, in no way means that you can't build a good, secure website on the LAMP stack.
It's just a (rather obvious) fact that if you're a bad developer, then you're going to build an insecure site, most likely on LAMP. If you're a good developer, you're probably going to build a good site, which might be on a less common platform, but equally as (or more) likely on LAMP, too.
Might sound strange but: Yes it is. Since the first JDBC DB drivers it's common sense to use prepared statements and not build a query on your own. Because of this SQL injection is a much much smaller problem in Java codebases than in PHP ones.
(this being a Java culture result more than a language one).
I meant than PHP. The implication seemed to be "WordPress is made with PHP, and WordPress isn't bank-quality software, so would you want to trust your money to something made with PHP?" I would trust the credentials of the people behind the site before I'd even give a second's thought to the programming language. (Of course, that doesn't help Mt Gox much either.)
Totally off-topic, but I find this attitude curious. What makes you think facebook would do something of that sort? What possible evidence do you have for the potential of this sort of outright criminal behavior?
It seems to me your loathing of facebook is completely irrational. Unfortunately its this irrationality that drives most discussions regarding facebook in tech circles.
If someone is a known thief, it stands to reason that they will probably steal again if the price is right. Zuckerberg showed, unambiguously, that he will not only steal ideas but sabotage the people he's stealing from. I would say very little is beneath such a person.
To be fair, you need to put your real money somewhere like a bank. You don't need to put your Bitcoin anywhere except your wallet, so there is no reason to keep your Bitcoin in Mtgox unless you are trading it. Keeping all your Btc in Mtgox is more like keeping all your money in your Paypal account, and who in their right mind would do that?
It was crypt-MD5, the fact that they call it MD5 with salt is generous at best. They seem to have made the decision to move to crypt-MD5. I don't really have any faith in their ability to secure the servers.
> Even with the iteration count, SHA512 is not exactly meant to be slow.
Increasing iteration count is synonymous with intending something to be slow. BCrypt itself uses a default of 2^10 iterations in most bindings. PBKDF2 + and an NIST studied hashing algo like SHA512 is a perfectly valid method.
I can't see how it could mean anything at all. Your password is either salted or it isn't, a hash can't really be said to have multiple salts. Maybe they're using different salts in their various rounds of hashing, can't see how that would provide any more security.
The reason you're being downvoted is because this has been explained a fair number of times on HN. The problem with using SHA-* or MD5 for hashing is that those algorithms are designed to be fast. This means that it's relatively easy for a cracker with a dump of the database to bruteforce passwords, since they can try gazillions of combinations very quickly. Hell, they can even parallelise the task on EC2 and get it all done in an hour.
By contrast, computing bcrypt takes a significant amount of time and CPU. It's slow. It's designed to be slow. It's designed so that you will need a LOT of CPU power to bruteforce it.
So, no, SHA-512 is not much better than MD5. It's still a fail.
Many are forced to use insecure hashing for compatibility reasons with outside vendors. Google email for orgs/colleges has two options for hash exchange (or used too... it may be different now) MD5 and SHA1. So you could not migrate user accounts unless the hashes were MD5 or SHA1.
What bothers me most is the bullshit explanations that were given initially. Claims of a DB dump being stolen from a financial auditor's laptop, assertions that no SQLi vulnerabilities were reported and couldn't have been responsible, etc. If it weren't for the full-disclosure post about various vulnerabilities in the site, would they have ever admitted any of this?
What this means is that very easily, or even accidentally, MTGox could be running a fractional reserve bank in bitcoin. Balances are just numbers in the database, so there's no cryptographic requirement that they sum up to the actual amount in the dollar and bitcoin escrow accounts/wallets.
They can inflate the bitcoin in circulation, and all it takes is enough real bitcoin and cash to cover the withdrawals for no one to know the difference.
By using floating point values for a user's balances (per-currency) in the DB, they effectively did make themselves a fractional reserve bank, even if the spread was likely small. Most every transaction would've added a tiny bit of an error value -- given enough time, this would've added up pretty considerably.
No. If you were to repeat an experiment a million times, the standard deviation should (quickly) limit to zero. That does not mean that the value compued is correct, however. Due to how round-off is specified, the estimated error will increase with every floating point operation.
If not for loaded terms like 'Bank' and 'Exchange' people would think about this rationally and demand that all services buy comprehensive insurance to cover situations like this. Unfortunately they've been lulled to sleep by things like blanket FDIC coverage that, while it pays out after a crash, pays out in weakened money.
Bitcoins provide a chance for trust to be based on economics (escrow, insurance, audits, etc) not by government fiat. But you can't fall asleep at the wheel and just expect everything to work.
By that argument, an exchange is a legally defined concept and MTGox isn't one of those either.
MTGox is not a legally regulated bank. They are not a legally regulated exchange. They DO hold accounts on behalf of their customers, performing the function known as "banking". They DO execute trades between their customers, performing the function known as "an exchange".
It's a further resource out to the central bank information in various country which further goes towards information on legal definitions of a bank in each country (at least many of the links provide such information). If you have a better site for international banking law definitions separated by country, it'd be awesome to suggest it.
Mt.Gox really is an exchange; the whole point of the site is to convert between BTC and USD. If you wanted a bank, you'd use something else. It's also not clear to me that it's safer to store BTC on a server.
It is an exchange, but hackers are having a field day. People are realizing what the world realized many years ago: we need banks. I feel like bitcoin is going through all of the growing pains and making the same exact mistakes we already learned about currency.
That is indeed what it sounds like, but what's really worrisome about that is that anyone who thinks the solution to keeping passwords is to triple-salt them really needs to learn some things about keeping passwords safe.
I could quintuple-salt my passwords with 4096 byte salts chosen purely randomly and there would be no perceivable advantage over a single 512 bit salt.
Not necessarily. Let's say the salt is a combination of a per-user salt in the database, a per-user salt from a file on disk, and a per-system salt that's entered at the console at startup and held in memory.
A DB compromise doesn't reveal the other 2 salts. A full filesystem image doesn't reveal the third salt. Even an interactive root compromise would need to know to take an image of the running system's memory to get the third salt.
Why reinvent the wheel using engineering techniques you only have cursory knowledge of from reading an encyclopedia?
There is a standard method of securing online accounts, using known methods that are currently known to be perfectly safe in every application from financial institutions to the latest social networking site. Triple-salting passwords is not that method.
I wasn't advocating this method or defending Mt. Gox. (Their touting of SHA-512 and use of the unclear term 'triple salted' raises red flags.)
I was providing an example of what could be meant by 'triple salting' that didn't necessarily involve 'three servers'. We could contrive scenarios where bcrypt with this multisource-salt would be a win over bcrypt with a single same-database salt. Intellectually exploring the problem and solution space requires more than just slavishly repeating the already widely-known 'standard methods'.
Have we worked together at a level that would help you assess my level of knowledge, and the sources thereof? I don't recognize your name/handle.
No, we haven't worked together. My "cursory knowledge" comment was more directed at the people running MTGox, not you. Sorry if I phrased it in such a way to imply so.
I agree, there could be an implementation where applying multiple salts might have a benefit, but SHA-512 is not that implementation. I was not slavishly repeating 'standard methods', but pointing out that they are or were widely wrong in whatever they were doing to begin with. An MD5 is hilariously weak for password hashing, and salting an MD5 only makes an extremely weak password hashing scheme moderately weak. It honestly sounds like they took the first hashing implementation with the largest number tacked on the back of it that came to mind and called it good. This is not the right thing to do, and anyone that 1) cares about the security of their online web app's users information, and 2) has spent more than 2 minutes reading about the correct ways to secure an online web app, should be able to figure this out.
Point being, the fact that they originally only had MD5, and then "upgraded" to a salted MD5, and now are going to a triple-salted (whatever that means) SHA-512, is a BIG clue that they really don't know what they are doing, and a complex homebrew triple salt implementation that passes a password to 3 different places to be salted is bound to be broken. Unless they have hired a well known experienced cryptographer, I wouldn't trust MTGox with a dime of my internet money.
There are plenty of ways that you could use 3 different salts without it having to pass through 3 servers, but I was specifically responding to the OP, where he spoke of 3 salts in 3 different servers.
They could be using 3 different salts, each of which is statically stored on the server. They could be using 3 per-password salts, and applying each of them once. They could be....
At the end of the day, salts are there for one thing alone: eliminating the possibility of rainbow tables. But whether you use 1 salt of decent size (64-bit minimum for that) or 1000, you've got the exact same protection there. There's a good reason it's recommended that you use PBKDF2 or bcrypt.
No, it doesn't. Once the salt is large enough that you don't have several passwords hashed with the same salt value, there is absolutely no further advantage. Frankly, 64 bits of salt seems like enough for anything. Triple-salting sounds like a technique made up by an amateur who doesn't understand what salting is supposed to do.
Right, but this doesn't make the search space 2^64 times larger, or anything of the sort. Once you've assigned a unique salt to every password, you're not getting any further benefits from salting. This is what the Mt. Gox owner doesn't seem to get, with his "triple-salting".
The NIST application involves generating keys from passwords, which you might do a gigantic number of times for every password to get unique sessions and so on. They're not talking about password storage. And even then, 128 bits seems like a huge overkill, which was included just because it's cheap, so why not. I don't mind 128-bit salts, but let's not promote that as some "ultra-secure" feature, which it isn't.
I think Thomas Ptacek takes it a necessary step further: "Don't implement crypto." Even if you're using a good algorithm, your implementation of it will have holes. The trouble is that the normal exploratory programming technique that gets a MVP up and running doesn't find security holes.
Yeah, when this very first happened, I was in the IRC room at onlyonetv interviewed Mark (via proxy). I kept shouting in IRC to ask them to use bcrypt and was told they were doing 1000xSHA-512. I later tweeted at MagicalTux to recommend bcrypt and was asked if multiple iterations of SHA-512 is good enough. He said that he was told bcrypt was not secure enough.
How do these businesses succeed with business people that have no business wit about them, have NO ability to communicate effectively in these critical situations and have awful taste in technical advice?
Google "bcrypt sha-512 hash passwords" and tell me if it's a hard call to make. You should have heard these guys within the first 36-hours answering questions. Even the business guy over at TradeHill, "Well, you know after mtgox, we need to do a lot to beef up our security". Even if that's a true statement, what a ridiculously terrible way to phrase it.
I think speech and debate classes should be required for everyone to graduate highschool, let alone college. People aren't good at thinking on their feet and speaking in critical situations where wording makes a difference.
When you're in the business of being an online bank for an uninsured (nearly) untraceable currency, mis-speaking like this costs you your most important asset: TRUST. That's not even touching the tip of the iceberg of lies and misinformation that has come out of mtgox.
Anyone that leaves a penny in any mtgox account is an idiot.
>How do these businesses succeed with business people that have no business wit about them, have NO ability to communicate effectively in these critical situations and have awful taste in technical advice?
They take off because they are excellent, useful and timely ideas. Unfortunately, people who have strong, timely ideas, like this one, frequently aren't able to find good technical co-founders, probably because of the "ideas are worthless" meme so many hackers love to recite nowadays.
So the ideas take off anyway, but the sites basically don't have the technical architecture that they should and have to be rewritten later.
It's a shame that they can't be bothered to learn about security, since they're in the business of holding other people's money. It seems that they have killed their amazing opportunity, and deeply harmed the public's confidence in bitcoin at the same time.
Ideas are worthless refers to the fact that an obvious thing is obvious - I would argue that most ideas that go on to become successful products are obvious. Seldom are they really revolutionary. The implementation might be, but the idea itself seldom is.
In the current case, well just because it isn't perfect from a technical standpoint, doesn't mean it wasn't the best execution of the idea out in the wild...
BCrypt 1 iteration test script:
(same as above but with `1.times do`)
# => That took 0.074209 seconds
SHA512 1000 iteration test script:
# => That took 0.004092 seconds
SHA512 at 1000 iterations is over 18,000 times faster than BCrypt at similar iterations; which, by the way, makes no sense to do.
BCrypt has a "cost" factor, which is used to adjust the computational complexity to your use case. This is why BCrypt makes so much more sense for password encryption than something like SHA512. Running SHA512 n times is just a cheap, ineffective imitation of BCrypt.
What is the benefit of bcrypt over several million rounds of SHA-512? It seems to me that repeating the hash function is the adjustable work factor that bcrypt seeks to allow and SHA-2 is already in most languages without an additional library.
What is the benefit of bcrypt over several million rounds of SHA-512?
Most advances in cracking cryptographic hashes is not from Moores law, but some insight or breakthrough in the underlying algorithm. i.e. someone figures out a way to make MD5 brute forcing 2^(lots) faster. Usually these are not done overnight, but are chipped away bit by bit.
We are getting there with SHA512. The edges are starting to give. Warning signs are apparent. Eventually someone will reduce it to nothingness. 1000 iterations of nothingness is nothing ness.
SHA-2 is already in most languages without an additional library.
Oh dear god this is a terrible way to make a security decision. You have to install software no matter what you do. Unless you're writing software with a magnet in raw machine code, you will have to install additional software. Take the few minutes to install the bcrypt library.
Not much. You are perhaps a little more likely to find super-tuned GPU/FPGA implementations of SHA2 than pessimized blowfish, but it's not inconceivable for someone to write the latter. bcrypt is easier to pronounce than PBKFD2.