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.
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.)
The Java language is designed for safety, above performance, and ease of creating code. So it is more expensive to create a Java financial system. But safer.
The quality of your programmer makes more difference than your choice of language and libraries. But your choice of language and libraries has SOME effect. And Java tends to be safer than PHP.
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.
> don't disagree with most of what you said, but...you sure about this part?
Yes. I am sure. I have far, far, far less than 0.000001% of the total money in the bank. If they could not produce this much money when I wanted it, there would be other serious problems.
> Or if you want a more practical example, keep watching Greece
If I was in Greece, I would not have my money in one of their banks.
> Yes. I am sure. I have far, far, far less than 0.000001% of the total money in the bank. If they could not produce this much money when I wanted it, there would be other serious problems.
Last year, a branch office of a large bank in Finland was barely able to produce 10 000 euros in cash when I wanted to withdraw it.
The clerk just didn't realize he shouldn't mention it.
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".
They're not autonomous though - individual branches don't hold the value of all their customers' accounts as cash. You're subject to a daily limit (though you can take more if you give them notice).
Now we're just being pedantic. My point was that each branch should have enough cash to act as a "proper bank", whatever amount of money you'd reasonably expect one to have in its vault.
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 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.
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.
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.
I was more referring to the fact that we fail to produce proof of the limited amount of gold that we claim to have and every attempt to audit it is rebuked magically.
In terms of the question, how would it be handled from an FDIC perspective if it came to a worst case scenario... it'd be a shit-show.
I was more referring to the fact that we fail to produce proof of the limited amount of gold that we claim to have and every attempt to audit it is rebuked magically.
I think you're just rambling. Our currency isn't gold backed -- who cares how much the US govt. has in gold repositories and why does it need to be checked?
No he isn't.
If ( just for the sake of the argument ) RMB replaces USD as the international currency base, US has absolutely nothing to back dollar value and prevent it from dropping.
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.
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.
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.
I don't really see it. FDIC insurance promises to give you dollars. Worst case, they just start the presses.
A precipitous drop in the value of the dollar would be unpleasant (including for for Americans with savings), but I don't see what FDIC has to do with it.
They would just call up the federal reserve and have them print money. When accounts close down it's money that disappear from the money supply that the fed would replace.
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.
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.
True, but I think this has been fixed, assuming their new site is live:
"The new Mt. Gox site features SHA-512 multi-iteration, triple salted hashing and soon will have an option for users to enable a withdraw password that will be separate from their login passwords."
They could be using PBKDF2, but if they were, they probably should have said the magic words. Also, the iteration count is kind of important. If it's triple-iterated, that won't do much good.
Even with the iteration count, SHA512 is not exactly meant to be slow. They're taking the long way around to try and get the security of bcrypt... without just using bcrypt.
> 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.
Iteration is valid, but what is this about "triple salting"?
Googling "triple salted" sha -gox gives me 13 results, of which 3 are about caramel cupcakes and none are serious evaluations of such an approach. It sounds like homebrew security.
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.
Not sure why I'm downvoted, SHA-512 is obviously better than MD5 and we don't know the details. The constant spewing that bcrypt is the only way to hash a password is getting old fast.
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.
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?
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?
If I were the guy MagicalTux outright accused of being the hacker and threatened with FBI action, I'd be demanding a public apology right about now. He'll probably never get one.
The part that bothers me about that is "triple salted hashing". This could mean any number of things, all of which point to a misunderstanding of what a salt is for.
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.
Perhaps they mean it's salted by 3 different environments, so an attacker would need to crack the db server and 3 other servers just to get a chance to start cracking the passwords.
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.
That idea is absolutely not clever. It's a system that would be difficult to implement, fragile, and most importantly would provide almost no added security.
Programmers: shut the fuck up and use a well known password derivation function. Stop the NIH wanking -- homebrew cryptography is about as useful as seeing the local witch doctor for a heart attack.
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.
Not quite the same application, but it would seem best to take a conservative approach and make your salts 128 bits because the storage required is so small - you are only storing one per username.
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.
1st rule of cryptography - don't try it at home. You'll get it wrong. There are any number of standard ways to protect passwords, there's no need for them to be reaching for the bottle of Snake Oil.
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.
No, it seems to have gone fine. A lot of people (including Mt. Gox) decided to start taking security more seriously, and the price of Bitcoin has increased slightly.
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.
No. Making Blowfish faster is equivalent to solving a hard cryptographic problem. We have a much weaker guarantee about SHA-512. While SHA is probably good enough, bcrypt is definitely better.
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.
A reminder that MTGOX originally stood for "Magic The Gathering Online eXchange". When a site designed for trading cards online turns into the world's biggest Bitcoin exchange you better believe there's not going to be an appropriate level of security underneath it.
It doesn't really seem like a dig at the MtG subculture, IMO. It's just natural that a trading card site probably would focus less on security than a financial institution. This has nothing to do with the people or the hobby involved, and more to do with the fact that pretty much nothing needs as much attention to safety as a bank/currency storage.
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.
Bitcoin7 was called out for floats, but they actually weren't. MtGox was, but isn't anymore. It was reported in full disclosure, then confirmed on IRC later, although I don't have logs handy.
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.
There is a difference between reading the statement as "mtgox offers some services which make it look bank-like" and "mtgox is definitively a bank as defined by applicable laws".
The difference, in case you're curious, is willful pedantry, and really just clutters up the thread.
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".
Not sure about the logic:
1. All banks are defined
2. Me: You cannot claim banks are the same everywhere
3. "Pretty much every country" == not everywhere
So you agree, or you disagree? Sorry to stick with Aristotelian logic.
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's fine, but it doesn't change the fact that Mt. Gox is sitting on untold amounts of users' funds, in both hard currency and bitcoins.
I've got 70 bitcoins in their system, and they have not responded to any attempts to contact them for two weeks now.
I've even gone so far as to contact Mark Karpeles directly through LinkedIn, and nothing.
They have lost all credibility. Aside from the fact that no one will ever trade with them again, the most likely next scenario is a flood of lawsuits from Mt. Gox members who have lost their money.
What about Citibank, where you could read other people's accounts just by adding the account number to the request parameters (I think it was the account number)?
We can attempt to blame the owner of the compromised account for the recent events but at the end of the day the responsibility to secure the site and protect our users rests with us. The admin account responsible had more permissions than necessary, and our security triggers were not as tight as they could have been.
If Mt. Gox did find the hacker, what could be done? I feel like this would be opening up a can of worms between Gox and the Gov. Although Gox and its users (myself included) are the victims in the recent compromise, it may be possible that instead of sympathy (or justice) being served, it would be Gox on the losing end again. I can see the House Sub-committee having a field day on Gox.
Maybe, maybe not. But this hack may be one without recourse.
I'm wondering why they don't offer users the option of using two-factor security, like Google recently made available to Gmail/Google App users. Being able to tie my gmail login to a secure passcode generated on my phone makes me feel a good deal safe, and I don't even have any really important information in my Gmail inbox.
why don't people use a private salts to beef up security? for example record the per-password salt in the db along with the hashed password but when calculating the hash concatenate the per-password salt with a salt stored in the program.
i realise it is kind of security through obscurity but in this instance the SQL injection wouldn't have compromised the private salt and it would have been much harder to recover the passwords. presumably, you would have to use a known pass/hash combo to brute force the private salt which would take a lot more computation time than recovering simple passwords.
"withdrawing the coins" in this case means moving them out of the BitCoin wallet owned by MtGox and moving them back into the BitCoin P2P block chain (as far as I know). There is no way to magically print more BitCoins like this (preventing this is one of the core design goals of BitCoin). This BitCoins had to come from somewhere. MtGox have admitted this and will have to buy/trade/get/acquire replacement BitCoins: "the 2000 BTC withdrawn did have real wallet backing and they will be replaced at Mt. Gox’s expense"
Yeah but its not like there's a discussion thread anywhere to critique the UI of MtGox's website, and these complaints have to be made so that these problems can be fixed.
March, 2011 – MtGox.com (Mt. Gox), now the world’s leading Bitcoin exchange, was purchased by Tibanne Co. Ltd. As part of the purchase agreement, for a period of time, Tibanne Co. Ltd was required to pay the previous owner a percentage of commissions. In order to audit and verify this percentage, the previous owner retained an admin level user account. This account was compromised. So far we have not been able to determine how this account’s credentials were obtained.March, 2011 – MtGox.com (Mt. Gox), now the world’s leading Bitcoin exchange, was purchased by Tibanne Co. Ltd. As part of the purchase agreement, for a period of time, Tibanne Co. Ltd was required to pay the previous owner a percentage of commissions. In order to audit and verify this percentage, the previous owner retained an admin level user account. This account was compromised. So far we have not been able to determine how this account’s credentials were obtained.
A quick search of Google for Tibanne Co Ltd leads to Tibanne.com:
Does this mean Mark sold Mt. Gox to himself and in the process created a superuser account so he could manipulate the exchange to his benefit? Sounds like he could be taking a page out of the Ultimate Bet / Absolute Poker playbook.
Probably would be willing to take him at his word if the explanation of the flash crash didn't change every few hours. And/or if he and others didn't mobb the guy who put in the low bid during the crash.
I suppose arbitrarily allowing someone to devalue an entire currency because of lax security procedures is technically better than evicting people out of their home.
> These guys make real banks look good - no small feat!
How, exactly? I don't remember many instances of banks having security issues that dropped the value of the US dollar to 1/1750th of its value, even briefly.
So some Bitcoins are 'real'. Huh. And the rest are 'imaginary' I guess. From where I sit, they all look imaginary.
I haven't seen a 'real' stock certificate in 20 years either. But stocks are actually backed by something, somebody.
Bitcoins are backed by ... a sysadmin? An algorithm?
I'm reminded of when bond trading changed - folks stopped buying the bond, and instead just bought a 'coupon' representing the interest on the bond. Whaa? Kind of like betting on the horse, instead of owning the horse I guess.
So, bet on Bitcoins all you like. But when you get burned, its not very ingenious to complain about it.
Sure, and 'real' stock certificates exist in a database too.
But they are backed by something. Currencies are backed by governments. Bonds are backed by the issuing entity which has assets.
Bitcoins are as real as grocery store coupons I guess. No, wait, grocery stores have inventory and bricks-and-mortar, so no, not that real.
Its misleading to call something as soft as a Bitcoin a 'currency'. There, no analogies at all.
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.