No database backups. Sorry for avoiding the question.
I hoped someone else could clarify this. I don't have all the full details, and would hate to make incorrect statements. I also didn't want to jeopardise efforts to refund people.
From what I gather, there are no backups of the database. Only partial records for accounting which is being used to extrapolate balances. I'm not sure of the exact details, but I think they need a full view of the claims before payouts begin (like a big jigsaw puzzle) to properly cross match records. Hopefully someone better informed will post more details.
zhou: ah, ok. I don't know the exact details and I'll avoid commenting further.
I think Patrick assumed they were not critical hence me saying: "The assumption here was that
[email protected] did not have access to critical infrastructure.". I do appreciate that several times, you told people I wasn't involved with Bitcoinica in this thread. I always
assume good faith which is why I think it was a fatal miscommunication between team members.
bitcoinBullbear: that's fine. It does annoy me a little that people assume that a decentralised system like Bitcoin consists of a single piece of kosher software. bitcoin.org
lists several clients. When security flaws were found, me, Mike Hearn and justmoon helped fix problems on the internal security mailing list. justmoon in fact was very instrumental in many cases for clarifying and proposing fixes for BIP 16. There was a long technical history that led to libbitcoin's creation and it has taken 8 months so far.
That picture is funny. I like it.
rjk, nope. Everyone had root. One person was installing a database, another installed Jenkins.
The anger here is justified. If this happened to me, then I would be extremely mad. I was very pissed at MtGox when they had their problems. It sucks to be no better than MtGox.
To the person above, here's what happened:
- Bitcoinica has an internet mailing list called
[email protected]- It was the email for the website and all sensitive accounts.
- You could request a password for that email. In a production system, that should never be possible.
- Several people had access to this mailing list (non-admins and business people included).
- Patrick got added.
- His personal email was compromised. Normally this shouldn't be a big deal; I use my personal email at internet cafes and public computers.
- Attacker was able to request a new password and login to rackspace.
The assumption here was that
[email protected] did not have access to critical infrastructure.
Lastly, it was my fault Patrick's email server got compromised. I had a VPS for programming and development which many people had access to - randoms from #c++ IRC, people from this forum, beginners I was teaching .etc It's a public VPS for development. The SSH key on there was added to Patrick's server because we were developing the bitcoinconsultancy.com website on there (that's why it's now down). My SSH key was stolen and he ssh'ed into the box. Then had access to his emails.
Bitcoinica took us on to help secure them.
We decided it was bad practice to make sudden disruptive changes overnight to a production system. Instead the theory was a very gradual replacing of the system while observing changes. Bitcoinica was already very fragile. I still think that was a good decision.
Step 1 - fix the code.
Flaws were already being found in the code. That was the logical first step. That the environment ended up being exploited is simply hindsight. I would prefer not changing a working environment until after knowing how the code operates. An example is that another website accidentally made out a 500 BTC payment when the file permissions were too strict. Similarly changing an aspect of Bitcoinica without proper insight could have had grave consequences.
First you understand the code. Then you run the code. You experiment with a test system. Make improvements. Deploy changes. Change production environment.
The Bitcoinica plan was to do the above while creating a new platform to replace it in the long term.
