[sillysaurus3]

Keys are created and encrypted in the browser

Key hijack in 5... 4... 3...

Browser crypto isn't secure. One way to offset the risk is to use a browser plugin to perform the crypto operations, and even that isn't really a security guarantee.

When you combine an incentive to break crypto (money) with a straightforward route to breaking it (browser crypto), you get a pretty dangerous situation.

[drcode]

Though I agree with you this leads to risky security issues, the mere fact that a major Bitcoin exchange is allowing users to hold their own private keys really puts a smile on my face today.

It is completely unheard of in the financial industry (and usually technically impossible before cryptocurrencies) to have a bank give away their "middle man" access of people's money and empowering their customers with complete control over their finances.

[jerguismi]

Which makes me wonder... The keys are generated in-browser. What if the users computer is compromised, and a malware succeeds in capturing the keys + bip38 passphrase? I don't know if this product will be pain in the ass for coinbase, if the user funds start disappearing from these multisig addresses.

All the best luck for this product, though.

[adrianmacneil]

If the computer is infected, then yes it would be possible to steal both the private keys, and the passphrase. To avoid this attack scenario, we're investing pretty heavily in technologies such as CSP.

However, this can be mitigated with our group multisig vault, where separate users create their own keys. For malware to steal these, it would require infecting multiple computers.

[icebraining]

Seems like the next step would be to allow the users to store their copies on a smart card instead of a PC.

[wcoenen]

Like the Trezor[1] hardware wallet.

[1] http://www.bitcointrezor.com

[icebraining]

Yes, but maintaining the encrypted copy on Coinbase's servers, to ensure that losing the card doesn't mean losing the wallet.

[wcummings]

CSP?

[floatrock]

Content Security Policy -- http://en.wikipedia.org/wiki/Content_Security_Policy

basically headers that can tell the browser not to execute stuff that leads to injection like inline javascript or inline styling, allows for whitelists of domains (so the browser won't run script src="http://hackercdn.com/malicious.js"), etc.

[adrianmacneil]

The only argument here is that crypto on internet connected (and potentially compromised) devices is insecure. There's nothing inherently more insecure about browser crypto.

Our multisig vault relies on BitcoinJS, which we had audited by an external consulting firm. We also don't allow multisig vault creation on browsers which don't support crypto.getRandomValues()

[sillysaurus3]

The only argument here is that crypto on internet connected (and potentially compromised) devices is insecure.

Actually, that's pretty far from the standard arguments: http://matasano.com/articles/javascript-cryptography/

That's pretty much the seminal work of why browser crypto is insecure.

The issue isn't whether the primitives you're using are secure. It's that the security of your primitives can be hijacked by any third-party javscript you load into the page. Any attacker that can gain a foothold into your javascript execution environment can trivially subvert your security.

[firepacket]

Assuming your are using SSL, what exactly is the attack vector for getting a "foothold into your javascript execution" besides hacking Coinbase itself?

Also, any attacker who gains a foothold of your operating system execution environment can trivially subvert your security as well. Does that mean crypto is broken on PCs?

[sillysaurus3]

any attacker who gains a foothold of your operating system execution environment can trivially subvert your security as well. Does that mean crypto is broken on PCs?

Yes, of course your crypto is broken if an attacker has malware running on your device. The difference between that scenario and Coinbase is that your device only affects you. A break in Coinbase's security will affect hundreds of thousands of people.

Assuming your are using SSL, what exactly is the attack vector for getting a "foothold into your javascript execution" besides hacking Coinbase itself?

There are at least three vectors. First, XSS. If Coinbase ever has an XSS vuln which allows JS to execute in the same context as their crypto key generation, then that attacker can silently siphon keys as they're being generated. Once enough keys are under their control, they can transfer the BTC of every account they control to the attackers' own wallet.

Second attack vector: Third-party JS libraries. If Coinbase is loading JS from any external source, any rogue employee from that source can launch the above attack. This attack may seem unlikely, but greed makes people do strange things, and the amount of money able to be stolen from a successful attack on Coinbase will be in the range of millions, if enough users start using multisig vault.

The third attack vector, which a sibling comment mentioned, is a rogue browser extension. Several extensions request permissions on "all websites," and users happily approve them. Now, you can say "Those people deserve what they get," but that's unproductive victim blaming. The fact is that users already behave this way, and letting them lose thousands of dollars for approving some silly extension like "Cloud To Butt" isn't a good thing.

Banks do a pretty good job of defending people's money. If they lose people's money because they're attacked, the bank will still credit the money. Would Coinbase?

[imaginenore]

> First, XSS. If Coinbase ever has an XSS vuln which allows JS to execute in the same context as their crypto key generation, then that attacker can silently siphon keys as they're being generated

So a very very very specific XSS vulnerability that affects the key generation process. I'm pretty sure that can be solved by not allowing any user input during the generation.

> Second attack vector: Third-party JS libraries. If Coinbase is loading JS from any external source

So don't load any external JS libraries on the key-generating pages.

> The third attack vector, which a sibling comment mentioned, is a rogue browser extension.

That's ridiculous. If you download malware on any OS, and allow it to run, it can do whatever within whatever permissions you allowed. Malware has been stealing money and identities long before Bitcoin was invented. Users need to learn not to install crap.

That can also be solved at the browser level - a website should be able to request a secure extension-less mode.

[spacefight]

> So don't load any external JS libraries on the key-generating pages.

And anywhere else. The local banks in my country are not doing this. And a wallet site shouldn't ether. Even the coinbase login screen pings olark.com all the time.

Oh, and if you look at their CSP report sending back home, the original-policy is quite scary.

"original-policy":"default-src https://www.coinbase.com https://*.olark.com; connect-src https://www.coinbase.com wss://ws.pusherapp.com https://api.mixpanel.com; font-src https://www.coinbase.com https://*.olark.com; frame-src https://www.coinbase.com https://*.wpstn.com https://h.online-metrix.net https://*.siftscience.com; img-src https://www.coinbase.com https://i2.wp.com https://secure.gravatar.com https://secure.etrust.org https://ssl.google-analytics.com data:; media-src https://www.coinbase.com https://*.olark.com; object-src https://www.coinbase.com https://*.olark.com; script-src https://www.coinbase.com 'unsafe-inline' 'unsafe-eval' https://stats.pusher.com https://cdn.siftscience.com https://*.newrelic.com https://*.google-analytics.com https://www.google.com https://www.youtube.com https://*.ytimg.com; style-src https://www.coinbase.com 'unsafe-inline'; report-uri https://www.coinbase.com/csp-report","referrer":"","violated... https://www.coinbase.com 'unsafe-inline' 'unsafe-eval' https://stats.pusher.com https://cdn.siftscience.com https://*.newrelic.com https://*.google-analytics.com https://www.google.com https://www.youtube.com https://*.ytimg.com"}}

[sillysaurus3]

A hypothetical extension-less mode isn't a bad idea. Unfortunately, it doesn't exist.

An XSS attack in an unrelated part of the webpage can escalate. If someone hijacks the session key of an admin, they get access to the admin panel. That access may or may not let them further escalate their privileges. If they manage to break into the box that serves the JS for the key generation page, then they can alter the JS however they want, including so subtly that no one will notice it's broken. Think this is unlikely? Privilege escalation attacks like this happen all the time. Again, the potential payout for a successful heist is in the range of millions, and due to bitcoin mixers, they're less likely to be caught.

Also, I bet at least one person reading this has the "Cloud To Butt" extension installed. It's not only untrained users who install that sort of thing.

[BillinghamJ]

Coinbase is insured, so in theory yes.

[sillysaurus3]

Really? Insured by who, and to pay out under what circumstances? What if every coin disappeared tomorrow?

[wmf]

what exactly is the attack vector for getting a "foothold into your javascript execution"?

Browser extensions? Those have been stealing BTC for a while.