Bitcoin, Mt. Gox, and 8 Lines of Code
In an article I had published in infoTech Spotlight discussing security and the Gawker database hack, I argued that it’s relatively easy to protect your user’s personal data against a database breach. The idea isn’t new – as a matter of fact this particular implementation dates back to 2005, and you can be sure it was known well before then.
Faced with a similar breach, Mt. Gox appears to have performed a little better. Although they originally depended on md5() hashing to secure their passwords (warning: do not do that), they came to their senses and started salting individual passwords much the same way as this article recommends.
Good for them. This is a great case study on how an organization who borked it was able to retrofit their code to protect their users. I applaud them for that effort. It may not have been perfect, but it was likely good enough for users who were smart enough to protect an account on a financial exchange with a half-way decent password.
As an aside, it’s a little disturbing how many of the nerds on the Hacker News don’t understand that not only is it ok to store the salt alongside the encrypted passwords in your database, it’s actually a good idea. Ugh. Another reason why developers should never be trusted to roll their own authentication schemes.
Unfortunately, Mt. Gox’s security lapse has come at a crucial point for Bitcoin. Bitcoin is an interesting economic experiment. I encourage you to read up about it as the official docs can explain it much better than I can here.
While it’s strictly true that Mt. Gox != Bitcoin, at this point in the evolution of the movement few people have the sophistication to understand the difference. So it might not be fair, but it’s still entirely possible that this incident could torpedo the movement. That’s unfortunate for many reasons, but it’s a reality of the world we live in. An upstart economy can’t prevail without trust.
It seems that 8 lines of code may not be enough.
0 comments