Hey Vertoe-
Mike from BitGo here with a few thoughts. We're working hard to up the ante on security, so we really value your skepticism.
You asked a number of questions, so let me try to address them individually.
Issue #1: What if an attacker compromises bitgo.com and changes the JS code to broadcast my keys somewhere?The core issue here is browser-based javascript. It's very hard (impossible!) to completely secure. You've probably read the Matasano analysis on browser-based JS code.
http://matasano.com/articles/javascript-cryptography/ There are many attacks that could lead you to getting bad JS code for your wallet, but I don't think attackers would try to attack BitGo's servers, as that is harder. The easiest approach is to get a chrome extension to modify the code in the browser.
But the simple answer is to simply not use browser based JS - instead use the Chrome App of BitGo. You can download it here, and it is not vulnerable to this attack.
https://chrome.google.com/webstore/detail/bitgo/jlgeogaipkoajobchncghcojanffjfhlBut lets suppose you were using the browser version of BitGo and the servers were compromised to serve up bad javascript. The malicious code would still not be able to access your keys unless it could trick you into initiating a transaction. Of course, it could lie-in-wait until you did do a transaction, but until you initiate the transaction and provide your per-wallet passcode, the malicious code would have nothing.
But lets suppose eventually you did type in your passcode and the malicious code got that. Now the malicious code knows your username, password, your wallet passcode, and your private key. Even with all this information, the attacker still can't coin arbitrary transactions (see my next note, below). The problem is that he needs to convince BitGo to sign your transaction as well, and that requires logging into your account, which the attacker can't do thanks to 2-factor authentication, which is required on all accounts.
What the attacker could do, however, would be to wait for you to make a transaction, and then modify the transaction to send to his own address instead of your intended address. For basic wallets, this would be an effective attack, and as I mentioned before, the protection for this is to use the Chome App version of Bitgo. However, for our enterprise-class wallets, this still would not be enough to compromise the account - thanks to BitGo's use of server side spending limits, address whitelisting, and multi-user approval requirements. The attacker might be able to get the transaction submitted, but a properly configured wallet would not allow BitGo to sign this transaction. If it did go through, it would be akin to stealing $300 from your ATM for an account that held millions.
Issue #2: I don't believe this is better than cold storage!Single-signature wallets, even in cold storage, are inherently less secure than any multi-signature, cold storage solution. If you don't want hot-keys (maybe you don't want to transact on the wallet), simply create your multi-signature wallet with 2 keys that are offline entirely. In this case, you can't use the BitGo website to transact, of course, but that's what you wanted - cold storage.
The reason this is better than single signature systems is because single-sig systems ultimately put all the key material onto a single machine to sign. And when you do that, if the machine has malware, your funds can be taken before you press send. With multi-sig, the two signatures are each applied on separate machines, making it very difficult for an attacker to steal. Combined with spending limits, this approach can still be used such that if someone does manage to bring one of the offline keys online, that they'll still have to get through the other spending rules before an automated signature can be applied.
It is fair to point out that BitGo doesn't have a web-based wizard for provisioning this type of cold, multi-sig wallet. We'll be improving that soon, but the API does exist, and many customers have used it.
Let me know your thoughts.
