| I can't really say anything you're saying here is false, but I still hope the lesson has been learned by most people affected. This wasn't 100% unavoidable bad luck and this kind of thing shouldn't happen to MtGox's victims twice. But perhaps I'm taking for granted my tech-knowledge(or bias opinion). Let me say some things that jumped out at me immediately as mistakes that should have never happened to begin with when making an application dealing with people's money. ---The password in URL thing. The issue with that password in browser's history is that it becomes an easy target for malware. Just like there's malware that knows the default location of wallet.dat, malware that scrubs your web history will find it. Making it worse is the fact that there are already a lot of malware that hijack browsers and monitor where it's going. At least wallet.dat can have a passphrase. Then you have those tools that are designed to help end-users by keeping their web history synced with other computers and/or devices. In short, web history is constantly exposed to 3rd parties so no personal info should end up there since you don't know how secure the 3rd parties are handling your data. At least, not passwords, SSN, etc. Another thing is servers tend to keep urls in access.log which tend not to get the same level of security consideration as the rest of the webapp. They should have sent it in POST body which isn't stored in access.log(at least not by default). ----The password hashing thing Security 101; you don't just hash passwords once with no salt. Existence of rainbow-tables make that insecure and even a novice should have known that before starting. Also, according to this article[1] it was a "saltless MD5"[2?] hash. ----SQL vuln I don't claim to be a DB expert but I do know using stored-procedures, instead of concatenating a bunch of strings together partially from user-input to form an SQL statement, makes SQL injection nearly impossible. I also believe there are some nice SQL sanitation libraries out there. But I can't judge this too hard because I don't know exactly where the SQL injection happened. Sometimes hackers do something really clever and put the malicious SQL in a place that's not normally user-input; like a cookie value for an authtoken. ----Trades roll back I did not see that solution as a valid way to do things. I still don't fully understand how that didn't screw over all kinds of people. Can etrade.com decide to roll back 1 day of activity? I dunno; all these things put together just gave me the feeling that one day these guys would be in trouble. The right thing to do after first, or at least 2nd, hack was a full audit of their whole system by someone who knows about these things. They just didn't show any signs of learning from their mistakes. e.g., like the postmortems that other companies sometimes post up detailing the problem and steps to recover. MtGox seemed to just be reactionary and only enough to solve the immediate problem. I'd advise anyone going forward that if you see similar behavior in anything you deal with, not just bitcoin-related, you run away. Also, a red-flag for me is any system where it's easy to put money into but hard to get out without a very sensible reason. 1. http://www.dailytech.com/The+Death+of+Bitcoins+Mt+Gox/articl... 2. This article claims there was a salt... http://www.dailytech.com/Inside+the+MegaHack+of+Bitcoin+the+... |