You think you don't need to trust blockchain.info ? Think again

[davout]

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 !

[1713575512]

1713575512

[1713575512]

1713575512

[1713575512]

1713575512

[1713575512]

1713575512

[hamdi]

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

[realnowhereman]

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.

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).

[davout]

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

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.

[phatsphere]

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

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

[davout]

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

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

[realnowhereman]

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

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

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.

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

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

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.

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".

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

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.

implemented and the operator is reactive. With a hosted wallet you can only steal a fixed percentage of the funds.

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.

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.

That is certainly true.

[realnowhereman]

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

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

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.

[piuk]

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.

[davout]

1) Javascript verifier is almost equivalent to having a signed browser extension. You still have to trust the operator somewhat.

Interesting.

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.

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

3) You can backup your own wallet, no need to trust the operators backup schedule.

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"

4) The iPhone and android apps are not vulnerable to server side hacking at all.

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.

5) Watch only wallets.

Very nice but irrelevant to the topic.

6) The wallet side of the site is open source (Server Side iPhone, android)

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.

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.

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

8 ) Two-factor authentication not available with Desktop clients.

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

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.

That's a good point.

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.

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.

[realnowhereman]

You've mentioned it a couple of times but I don't know what sense you're using it in. Please explain what you mean by "cold storage" and how it is made public in a way that stops it being stolen.

[davout]

You've mentioned it a couple of times but I don't know what sense you're using it in. Please explain what you mean by "cold storage" and how it is made public in a way that stops it being stolen.

What I mean by cold storage is using offline addresses.
Typically, the minimum possible is left on the server to reduce the consequences of a theft, should the server ever be compromised.
It requires monitoring to either send excess funds to cold storage, or reload the server if the amount of withdrawals largely exceeds the amount of deposits.

When your cold storage address is public, you cannot lie about getting hacked in order to steal user funds for yourself.
You can only lie about a hack and steal the funds that are in the hot wallet.

The same way, in the JS wallet model, an operator can claim having been hacked in order to steal a percentage of the funds using client-side code poisoning.

In both cases, a rogue operator can steal a percentage of the funds by claiming that a hack occurred.

[dogisland]

You've mentioned it a couple of times but I don't know what sense you're using it in. Please explain what you mean by "cold storage" and how it is made public in a way that stops it being stolen.

What I mean by cold storage is using offline addresses.
Typically, the minimum possible is left on the server to reduce the consequences of a theft, should the server ever be compromised.
It requires monitoring to either send excess funds to cold storage, or reload the server if the amount of withdrawals largely exceeds the amount of deposits.

When your cold storage address is public, you cannot lie about getting hacked in order to steal user funds for yourself.
You can only lie about a hack and steal the funds that are in the hot wallet.

The same way, in the JS wallet model, an operator can claim having been hacked in order to steal a percentage of the funds using client-side code poisoning.

In both cases, a rogue operator can steal a percentage of the funds by claiming that a hack occurred.

There's not much need for cold storage with a JS wallet as all the private keys are encrypted anyway. If the servers are compromised the hacker still can't spend coins.

On StrongCoin a hacker has about a 1 minute window to change the JS before it's detected and I get an SMS. In that time the probability of a payment going through is not large. They would be lucky to catch 1 password.

So that leaves the owners as the biggest risk, however that risk is far less then the old style e-wallets because we would be held accountable. We wouldn't be able claim that someone hacked the site, it would obviously be us.

So I think hybrid e-wallets are the safest and most convenient way to store your coins.

[davout]

There's not much need for cold storage with a JS wallet as all the private keys are encrypted anyway. If the servers are compromised the hacker still can't spend coins.

On StrongCoin a hacker has about a 1 minute window to change the JS before it's detected and I get an SMS. In that time the probability of a payment going through is not large. They would be lucky to catch 1 password.

So that leaves the owners as the biggest risk, however that risk is far less then the old style e-wallets because we would be held accountable. We wouldn't be able claim that someone hacked the site, it would obviously be us.

So I think hybrid e-wallets are the safest and most convenient way to store your coins.

Yes, as you say cold storage doesn't make sense on JS wallets.

I'm impressed by the code monitoring setup you advertise.

But I disagree on the safest option to store coins. The safest is to use a full client or light client (light client that doesn't get served any code whatsoever). That's the only way to not have to trust anyone.

[piuk]

when the address is public (see 1frtknx for instawallet's)

I don't consider leaving $100k in one bitcoin address a wise security decision, I don't care how "offline" it is. Mistakes happen in the worst ways possible.

When your cold storage address is public, you cannot lie about getting hacked in order to steal user funds for yourself.
You can only lie about a hack and steal the funds that are in the hot wallet.

There is no way to correlate the balance in that public address with full balance of instawallet users. There could be 50% missing and nobody would be any the wiser.

[jimbobway]

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

Agree that the title is too sensational.

[dogisland]

But I disagree on the safest option to store coins. The safest is to use a full client or light client (light client that doesn't get served any code whatsoever). That's the only way to not have to trust anyone.

That's probably the safest option for YOU. Because you have an offsite backup of your wallet right ?

I'm targeting people who are new to bitcoin, who might not be aware that they need to make backups including offsite backups. People who don't want to wait for the blockchain to download and all the other things that make the client unusable.

I think you're right to bring attention to this and I think the hybrid wallets bring value to the community. If there was a way to close the operator risk issue that would be great.

e.g. A third party trusted service that monitors changes to the site and reports issues.

[BitPay Business Solutions]

I don't consider leaving $100k in one bitcoin address a wise security decision, I don't care how "offline" it is. Mistakes happen in the worst ways possible.

+100k

people know the difference between the cash they carry around for routing spending, vs. their checking account, vs. their savings account, vs. their retirement accounts.

bitcoin can fulfill all those needs in various forms. pick the right service for the right function and it will be fine.

[SgtSpike]

I agree with davout in that no one should be touting any online wallet as a zero-trust service, regardless of how the private keys are dealt with.  But, I also agree with others that blockchain.info is one of the most secure and trustworthy platforms I've seen.

No one should be touting blockchain.info as a zero-trust site.  But it needs a heck of a lot less trust than other online wallet sites.

[flatfly]

I agree with davout in that no one should be touting any online wallet as a zero-trust service, regardless of how the private keys are dealt with.  But, I also agree with others that blockchain.info is one of the most secure and trustworthy platforms I've seen.

No one should be touting blockchain.info as a zero-trust site.  But it needs a heck of a lot less trust than other online wallet sites.

Anyway, nothing is zero-trust in life... Except death.

Everything is about risk management and not putting all your eggs in the same basket.