Bitcoin Forum

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 !

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

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

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.

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

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.

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.

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 (https://blockchain.info/wallet/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 (https://github.com/blockchain/My-Wallet/blob/master/WalletServlet.java) iPhone (https://github.com/blockchain/My-Wallet-iPhone), android (https://github.com/blockchain/My-Wallet-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 (http://blockchain.info/about), my name is Ben Reeves. This is me (https://i.imgur.com/U5iUy.jpg) at Ycombinator's (http://ycombinator.com/) 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.

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.

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.

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.

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.


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.

Agree that the title is too sensational.

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.

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

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.

"The safest" assuming you are better/equal at security than the guys running the web services.

How many non-techies do you know with computers?  How many of them have had viruses?  Should any of them rely on their local wallet installation to protect them?  Desktop computers are, statistically, far more likely to be compromised than servers.

what's the difference btwn holding that amount in one vs. many addresses?

With multiple wallets/addresses you need to capture multiple private keys tO spend the coins. As Ben said: mistakes happen in the worse way. If you only have one address run onmistake and EVERYTHING is gone.

i think it depends on the situation.

first of all, i'm assuming we're talking about rarely accessed savings wallets here where most of one's coins would be stored as in the $100K example piuk presented.

second, i'm assuming one has enough security knowledge to store these encrypted coins offline.

third, lets ignore rubber hose techniques for now.

thus, in this scenario, it wouldn't matter if one had the $100K worth of coins in one vs. many different addresses as the only possible attack vector would be a brute force attack of SHA 256 which is currently impossible.

It may be better in terms of detection.  If hacked and rooted and poison code sent which scoops up wallet.dat maybe it would be noticed before it got them all.  Hosted wallet, crack the box, get all wallets.  No time to detect and evade.  but you are right, code must be signed.  Maybe an app through the app store?

A Hash collision isn't inpossible.  Imagine a noob installing Bitcoin and upon downloading the block chain he sees 20,000 BTC ready to roll in his client?  Will he know what to do?

Davout did not say he was using just one address, did he ?
Even he was using one address why would you assume carelessness one his part more than on the part of piuk or any other bitcoin service operators ?
If one does not believe in the possibility to manage safely a cold storage address, one might as well keep using traditional bank services..

He said http://blockchain.info/address/1FrtkNXastDoMAaorowys27AKQERxgmZjY was Instawallet cold storage address.


In my view it's best to plan for the worst - The best laid plans of mice and men often go awry. Bitcoin doesn't exactly have a stelar history of services operators not making mistakes.

Client side encryption puts much less risk on the operator. Individually encrypted wallets, operator has no access to funds, User's balances are stored in the blockchain rather than an SQL db and users can backup their own wallets etc.

After sleeping on this something else has occured to me on the topic.

Certain hosted walelts that "do it right" (namely strongcoin and blockchain.info) may actually be *more* secure for many of the reasons stated in this thread aginst them.

The biggest one, that I have yet to see mentioned, is the isolation imparted by the browser. 

I think it has been hashed to death and we all agree that unless you are implementing your own bitcoin clcient 100% from scratch or you review each and every line of library code each time it changes that you are imparting some level of trust on someone.

In this regard the browser/javascript based wallets are acutally more secure IMHO because they are isolated and can only access the funds I give them the private keys for.  As opposed to a desktop client that feasbly could capture every bit-cent that flowwed through that system.

I just think the whole FUD against the managed wallets (again those who "get it right") is unbiased.  If you want to take a walk down the road of "what could happen if a solution provider woke up evil this mornign" then consider...

Most people install the desktop clients in binary form, and even those who compile their own don't check the source code.  Lets say that the Armory/Electrum/Satoshi (seems how we are picking clients with absolutly no proof or knowledge) developers decided tthey were evil and deployed slightly modified client that say for the enxt six months gathered every private key that ever passed through it, even paper wallets.

Then on a "bitcoin black friday" the evil dooers decided to empty all of those addresses.  Most people wouldn't even know until it was WAY too late, and the few people that were actually taking the propper precautions to prevent this would be inconsiquential compared to the funds they would actually capture.  Furthermore because they are desktop clients there are about 1000 and 1 ways that they could capture the wallet.dat files of other applications and exfiltrate them.

My point is: Unless you are one of a very few people in the community who write this from scratch, you are trusting someone.  That doesn't really matter if you are trusting them to write a library, a desktop client, or a website.

Also web clients have certain features I find very attractive such as:
 - There is no wallet.dat on any of my systems to steal.
 - I have two factor authentication to my wallet, so even if my password if compromised I still have a window of protection from my two factor which would be impossible to do correctly in a non-hosted solution.
 - I have access to my wallet on all of my devices, including my un-jailbroken iDevices.
 - It looks better than any of the other desktop clients I have tried.
 - I don't have to wait 2+ hours for the blockchain to download
 - Payment notifications

These are just a few of the things I can count off the top of my head.  If you decide that you would rather use a desktop client then that is great.  That is the great thing about choice, and we have alot of great (and for the record I believe trustworthy) sources to choose from.  But to spread FUD that is opinionated and uneducated is just irresponsible.

+1
I could not agree more. It seems that OP was trying to get the message across how relative these different perceptions of trust or trust model are.

Hosted wallets like paytunia or instawallet have been the target of biased and uneducated criticism.

I have said before how damaging it can be for an emerging technology like bitcoin to be subjected to an ideological stance regarding security and trust models when usability and reliability are equally important factors of adoption.

OP does not deserve accusations of being biased or uneducated, quite the opposite.

I stand by my words. I don't see how spreading the balance among multiple addresses would make the security model any stronger when they're stored in the same bank safe. But that's just my 25000 BTC. Plus I really like the transparency that it provides.

I'm stating precise facts. If a JS wallet operator wakes up one day and decides to steal your funds, he has a variety of options to pick from depending on whether he cares about getting caught or not, whether he has time on his hands or not etc. I think reminding this simple fact is a quite responsible attitude actually, because I believe that people tend to forget it or were never aware of it in the first place.

Stating a fact does not imply making a judgement one way or another.

If you think you do not need to trust the operator of a JS wallet when you use it, then you need to think again. It's not sensationalist, it's not an opinion, it's not a comparison, it's just a fact. It doesn't mean JS wallets are good, bad, better than X or worse than Y, it's just something that I wanted to remind to people who have an interest in JS wallets.

I for one appreciate you highlighting this fact since I was under the mistaken impression I didn't need to trust the operator of for example the blockchain ewallet on any level given the use of local encryption.

So thank you.

this is precisely why some of us like offline solutions like Armory.

Maybe piuk should make a link to this page in more places.  https://blockchain.info/wallet/verifier

Armory is a completely different use case than web clients.  I can't use armory from my phone to quickly send funds.

Yes absolutely. It's the first time I'm seeing it and I thought I thoroughly explored his site.

What transparency?  Without publishing every account balance, and having every user publicly verify that their balance is listed in that publication, the presence of an address with a balance doesn't tell us anything.  The site operator might have skimmed 10% off the total -- how does publishing the address with 90% of the balance on prove that that hasn't happened?


None of this conversation is FUD; it's an informative debate.

You've missed out one key option that JS wallets offer and hosted wallets don't: the ability to use exactly the same API as the JS does, but on a custom, unchanging binary.  Just like the blockchain.info app does.

In that case, the fully encrypted data is accessed only by the binary I obtained once and only once; would not be affected by any amount of site compromises and the encrypted wallet can be kept backed up on the device, so even in the event of a malicious site deletion (Bitcoinica anyone?) the wallet is still in my possession.  To me this is the optimum point in the convenience/security trade off.  The wost a compromised site can do is lie about new transactions being received or not received, and not forward transactions issued to its API.  It cannot steal funds from anyone.


I don't think that's true; the debate and comparisons going on in this thread definitely are to decide whether JS wallets are better/more secure than a hosted wallet.  It's my opinion that they are.

That doesn't mean every instawallet-like service is a scam or even untrustworthy.

I never said you didn't need to trust them, my point was you need to trust the publisher of any client you use.  This fact is no different with a desktop or web based client.

And while your quote above is correct it is also, in my opinion, misleading.  I believe that it implies that you do not have to trust the developers of other bitcoin clients, which is of course not the case at all.

You are correct, however the trust models are quite different for the official client versus a JS wallet.
The official client's code is extensively peer-reviewed and enables multiple different developers to check for the binary hash consistence.
A JS wallet dynamically serves code to you, it opens a LOT more possibilities.

A bitcoin developer cannot wake up one morning and decide he'll steal funds from already installed clients. A JS wallet operator has a variety of options if he wants to do that.

I would agree with the highlighted statements above.

And for my turn to somewhat spread FUD: I would venture to say that most people don't check the signatures when they download, so they are relying on others to do that for them and check for discrepancies.  Also not all clients either can or do that (Bitcoin-Qt on OSX for one).  So most are just assuming that the clients are valid when we don't really know for sure.

HOWEVER, I believe it is highly unlikely that any well known client developer (or commiter) would sneak in some back-door code to turn on at a later date.  Possibility vs probability.  Now Uncle Jimmy's S00per S3kr1t Wallet on the other I might not trust so much....

When I goto https://blockchain.info/wallet/ my wallet verifier extension gives the below message?

https://chrome.google.com/webstore/detail/kcapglakfcodkajgllmkiddclghogkic

Message: "*** Serious Error - Javascript inconsistencies found. Maybe malicious - Do not Login! Please contact support@pi.uk.com"

Also in the reviews one of the guy was saying the permissions seemed to have changed on the extension?

What's going on?

Since I switched back to firefox I haven't seen this massage yet but when I used chrome I did see this from time to time and usually if I refreshed the site the message went away. I know there's an explanation for this but I forgot what it is..

Why does blockchain's mywallet use a JS wallet and a browser plugin to verify it? Why not simply a browser plugin like lastpass? Wouldn't that be more secure?

The advantage of having the encryption and signing done in javascript is the source is available.  Can you make a browser plugin in javascript?  If so then it likely isn't any more secure but it certainly isn't any less secure.  If the browser plugin is running opaque code then it is significantly less secure than using javascript.

Even if your claims on security are completely correct, I still somewhat disagree. The single worst disaster relating to hosted Bitcoin wallets that we have had in 2012, Bitcoinica, was not due to malicious action - it was due to inaction and a bad default. Of course, the thefts did precipitate the whole debacle, but the money that was actually stolen is only about a third of the sum that account holders actually had, and the reason why the other two thirds still haven't been returned is because the money sat in Bitcoinica's wallet and so when Patrick et al simply sat on the money for two months by default that money was not accessible to users. With a Blockchain-like setup (obviously a strictly blockchain-like setup can't really be used for a Bitcoinica-like application, as it needs access to the money to operate, but that's beside the point here), the default would instead have been for users to be able to instantly access and recover their funds from a backup. It's not inaction, but active theft, that would be the threshold required for customers to actually lose any money - a threshold which, if you break and are caught, will likely lead to you going to jail.

FYI the entire discussion in this thread will with the arrival of hardware wallets soon be irrelevant. I hope that even blockchain.info will make use of them.

OMG YES

Sorry to dredge up an old conversation, especially when I obviously don't understand what is being said as well as any of the posters in this thread, but I had a question about the security issue discussed. here.

Would the dangers you discuss, server-side poisoning, dishonest site owner using any of the methods you discuss, etc., still apply in the case of someone who carried out the procedure of creating a wach-only address by logging in, disconnecting internet, creating the address in private browsing mode, printing out the paper wallet for the new address, deleting all traces in the browser, then logging in and importing the new address as a new watch only address?

I mean to say that if this procedure was done so that the address and private key were created offline and then if the user NEVER sent bitcoins out of that address, therefore never entering the private key for the transaction, would the site owner or someone who poisoined the code still be able to derive the private key in some way? I mean if a user had a watch only address in their wallet and never even entered the private key to send coins then how could the private key be captured?

Thanks for any responses!

I installed that javascipt checker mywallet 1.9 that tells me if the JS has had something injected into it....does this help much????

Switched over from blockchain.info wallet to an offiline wallet.

I sleep better.

Since this old thread has been necro'd I might as well post an update.

Fully packaged browser extensions are now available for Chrome and Firefox, which addresses the concern in the original post:

Info:

https://blockchain.info/wallet/browser-extension

Chrome:

https://chrome.google.com/webstore/detail/blockchain/glaohkkooicollgefkkmndjcbblominl

Firefox:

https://addons.mozilla.org/en-US/firefox/addon/my-wallet/