Topic: You think you don't need to trust blockchain.info ? Think again - page 3. (Read 14113 times)

Interesting.

An hosted wallet operator can hardly claim the cold-storage was hacked when the address is public (see 1frtknx for instawallet's)

This one can be turned around : "hey, with a hosted wallet you don't even need to back your wallet up, it's taken care of for you"

I'm not very familiar with iOS's sandboxing model, but I would hardly trust a jailbroken phone to keep my data secure. Hey, now you even have to trust the Cydia guys too!
Additionnally I tried to install the app from Cydia but I fails to start, which is a pity because it really looks great and I'd most definitely be willing to try/use it.

Very nice but irrelevant to the topic.

Theoretically that's a good point, but that means you'd have to compare the Github source against what you actually download. Regarding iOS/Android it doesn't change much when it comes to trusting the operator because you're usually installing a binary that has been compiled beforehand.

That's very good but irrelevant because you still have to trust the operator to actually deploy the published code.

I'm not sure I fully understand the implications. But I guess it wouldn't change much in case of compromised client-side code.
  
That's a good point.

It's not about trust in a person. It's about trust in a model.

My point is that the model behind client-side JS wallets also requires some trust in the wallet operator, whereas I often hear and read that they require none. If the operator of a JS wallet wants to get away with user funds and doesn't care about his reputation, he can get a good share of them. Yes it's harder than for the operator of a hosted wallet, but it's doable if you collect private keys over a few days. If the operator claims he got hacked he can only get a small fraction of the funds, which is true for hosted wallets too when the cold-storage is public.

Sensationalist title? I've never claimed that blockchain.info is zero-trust but it requires significantly less trust then hosted wallets.

Here's my 10 11 point rebuttal:

1) Javascript verifier is almost equivalent to having a signed browser extension. You still have to trust the operator somewhat.
2) With a hosted wallet the operator can make off with everyone's funds at anytime and say they were hacked. This is not true of blockchain.info and would be significantly harder to pull off.
3) You can backup your own wallet, no need to trust the operators backup schedule.
4) The iPhone and android apps are not vulnerable to server side hacking at all.
5) Watch only wallets.
6) The wallet side of the site is open source (Server Side iPhone, android)
7) All code running on the Site is signed and checksummed at the time of deployment. This checksummed is checked regularly, a log of changes can be seen at https://github.com/blockchain/Checksum/commits/master.
8 ) Two-factor authentication not available with Desktop clients.  
9) Having your own private keys leaves you in control of your money. If blockchain.info went offline for any reason you can just import a wallet backup into multibit, if instawallet went offline Users would be left high and dry.
10) The Site is operated by a registered UK company, my name is Ben Reeves. This is me at Ycombinator's offices a few weeks ago, anyone feel free to contact me at +44 7525 431876 (9-5 GMT).
11) Hosted wallets can change your balance at anytime, you can verify your blockchain.info balance in the blockchain.

A signed extension doesn't really protect you with JavaScript.  The open security model of the DOM means that you don't have to change the code in question; you can simply run some additional code that installs an event handler in an appropriate place to grab keys as they pass.

Agreed.  A JS wallet service requires the same amount of trust in the honesty of the provider as does a hosted wallet -- either one can, if they are dishonest steal your money.  Score: tie.


Same for both examples again.  You trust either their honest or their competence.


This is where we disagree.  The difference is in the effects when that trust is misplaced.  If it is simply that the provider is dishonest, then both are equivalent.  When it is trust in security that is misplaced, the effects are very different, as described in my first post.

That means that they are very different.  Your funds are at risk in both, agreed, but they are more at risk in a hosted wallet.  More steps and more time is needed to steal many wallets from a JS-wallet than from a hosted wallet.

Cold-storage is possible; it's just done differently.  The user is responsible rather than the host.  You would keep watch-only addresses in your online wallet, and create a paper wallet for your "cold storage".



Quite true; but the important point is that you had to qualify with "a carefully timed attack" (actually I would say it's not about being carefully timed, it's about being lucky enough to have every user log in so that you can steal their decryption keys).  With a hosted wallet there is no qualification: a break in means every user's funds are gone in the time it takes to copy the hosted wallet.dat off the system.


That fixed percentage is 100% though.  Unless you are assuming that the hosted wallet relies on most funds not needing to be live, so can be stored in a cold wallet?  That might be so, but doesn't change the fact that all of the hot wallet can be stolen instantly in a hosted wallet; but not in a JS-wallet.


That is certainly true.

Interesting, but it would IMHO make more sense to install wallet as a signed extension, instead of installing an extension that checks that wallet isn't poisoned with rogue code. Maybe I'm missing something here

have you looked into e.g. https://chrome.google.com/webstore/detail/kcapglakfcodkajgllmkiddclghogkic ?

Let me reword it : "using a JS wallet requires trusting the wallet operator too".

You have to trust that :
 - their servers are secure so the code won't get poisoned,
 - they've actually implemented the security measures that you rightfully mention,
 - more importantly : that they're honest

Which, IMHO makes it not that different from a hosted wallet. Additionally, some counter-measures cannot be implemented natively in a JS wallet, for example cold-storage.

If your JS wallet server gets broken in, a carefully timed attack could steal a very large percentage of the user funds unless the code monitoring you mention is implemented and the operator is reactive. With a hosted wallet you can only steal a fixed percentage of the funds.

Obviously it all depends on a lot of factors as you said, my point simply being that it's not a simple black and white situation as often depicted.

I think this is pretty well known; but I don't agree with your "not much safer than a hosted wallet" characterisation.

A hosted wallet, if compromised, reveals every single private key of every single user.  In one instant.  The breakin can happen and the thief can be away with a wallet.dat in seconds.

If a browser-wallet site is compromised, it's true that the javascript can be poisoned so that any subsequent user who logs in can have their keys stolen.  However, poisoned javascript can be spotted by the site owners pretty quickly (I'd be very surprised if they didn't run a cron job that regularly downloads and compares the known-good hashes of the scripts) -- that means that the damage is limited to only those users who login between the time the site is compromised and the time the compromise is detected.

Hence "not much safer" seems unfair to me.  The damage if blockchain/strongcoin is compromised is considerably less than if instawallet is compromised.

Is this as secure as a self-hosted wallet?  It depends.  Is the "self" we're talking about a security expert?  Are they likely to get keylogger or bitcoin-stealing malware?  How does the security of their desktop compare with the security of the blockchain/strongcoin servers?  I consider my security knowledge pretty good.  Therefore if I host my own wallet it probably is more secure than blockchain/strongcoin.  If my granny hosts her own wallet... not so much.

You haven't even considered the facilities that, say, blockchain give you to use blockchain as a monitor for a paper wallet it will help you create.


(incidentally, javascript's security model is so rubbish that it is effectively impossible to prevent code-poisoning from stealing keys, even with a signed extension).

have a standardized small javascript-app to sign transactions...
(like bitaddress.org is for address-generation)

This is true for all wallets that advertise in-browser cryptography.

They are all vulnerable to code-poisoning when the central server gets compromised.

To properly do javascript cryptography you need to publish a signed browser extension that therefore doesn't get served dynamically and therefore is invulnerable to server-side code-poisoning.

Basically, that means that blockchain.info, strongcoin.com, {insert client-side JS wallet here} is inherently less safe than a standalone client, and not much safer than a hosted wallet.

Thoughts welcome !