Topic: How can My Wallet be made more auditable? (Read 3348 times)

Thanks, but…

That doesn't really answer what I was saying... The site has the secret: otherwise it couldn't use it for notifications.  Okay, so supposedly the admins don't have access to it now—  but the same could have been accomplished all along by not creating a webform specifically for people to query by address or (if they have database access) denying them access to the relevant table/column. So I'm still not seeing how the hash added something material. Perhaps better than not, but it's really unrelated to the central issue of creating a whole user interface to query by something that many people believed wasn't even queryable by the site operator.

The only way I can see to secure this mapping is with the help of a third party.  Here is how that would work: the user would encrypt their private info with a random key and give it to blockchain.info. Blockchain.info would return a random ID for that blob.  they'd take every address for each address make a message Encrypt_to_thirdpary(address,Encrypt_to_blockchain(blobID||randomkey||nonce)) and give it to blockchain.info.  Blockchain would queue up and mix a bunch of these from many users.. and pass it to the third party.. who could decrypt them.. and watch for transactions. As transactions come in, they'd send a batch of encrypted blob IDs per block to blockchain. Blockchain would decrypt, and then decrypt the addresses and send out notices.

This would: Completely hide the private info from blockchain in the event that no notice is sent, make it easy for blockchain to not keep decrypted private info around accidentally,  obsecure the connection between addresses and personal info from everyone unless blockchain and the third party cooperate. It would thoroughly hide the connection between addresses in a wallet.  But if blockchain was analyzing when certain ID's got notified could eventually map out which was which— though someone watching their outbound email could too. It would have the downside of introducing points of failure and probably isn't worth the complexity. The third party would learn which addresses are being watched by blockchain users. But it would be an improvement in a way the hash is not.

https://bitcointalksearch.org/topic/m.1410363

Hm. This certainly wasn't my understanding of what the claimed properties were of the wallets, though I don't know how didn't remember it if it was on the site. 

I don't see how hashed addresses helps in the slightest against this particular incident when someone would query for a particular address. You could still query by address, the query would hash the provided address and return the match.  Someone could also still enumerate all the interesting addresses from a copy of this database: they'd just hash all the addresses in the blockchain and use that to reverse the hash for every address that has been already used.

Your understanding is incorrect. The address was not a mixer address, it was a regular wallet address which was in a wallet with notifications enabled. It has always been stated that the public keys are extracted from a wallet when notifications are enabled (https://blockchain.info/wallet/anonymity). This has been altered now to store hashed addresses only.

I believe this thread indicates that Roger Ver was able to trace the ownership of one of your anonymous addresses via administrative access on your systems.  At least based on a quick review this would appear to be conclusive proof that your claims about logging were inaccurate.  Or to be more specific, you in fact had a web query page available to staff/support/investors which allowed querying by data that you above claimed not to log. Not only was the data being logged, but it was intentionally being logged and there was an easy to use lookup tool. Can you correct my understanding?

The files distributed there are signed by a quorum of developers via the gitian deterministic build process.  The software released there is fully audtiable and anyone can download it, compare the differences to prior versions, and repeat the build process to get the exact binaries and contribute their signatures. It's not perfect— as not many users bother checking the signatures. But they can, and because there are no push updates even a small base of users checking provides a degree of protection.

It's not "a website" in this sense, because there's no log-in, the entire thing is stateless. It's a service that listens to port 80.


Let's go into detail:


MPEx only holds the user's public keys. You can safely talk to MPEx from an infected computer crawling with trojans and keyloggers (such as at a public library) and suffer no detriment, as long as you do your GPG-ing offline.


The hacker would have to attack the GPG installations running on each individual computer. This may be feasible, but certainly not on the same level of resources as the point discusses.


This is possible but meaningless: the user can always check transactions via the blockchain with any of the explorers for confirmation. In fact most sane implementations of Bitcoin on sites that sell something do not rely on a qt client running on the same machine to listen for incoming transactions.


The FAQ.


This is false for many reasons, chief among which are the public backups that anyone may download.


Not true. Use of MPEx improves the user's privacy from pseudonymous (as is the case with all Bitcoin users) to anonymous: all incoming transactions go into the same address, all outgoing transactions go out of one of the MPEx addresses, it is impossible for an eavesdropper to even establish who sent money in or out without ALSO breaking PGP. In this sense, using MPEx is actually better privacy than using any other wallet, including the qt client.

Hope that clears it up.

What are you talking about? Most of these do apply to MPEx or any online wallet in fact.

How do these same issues with centralized services not also apply to the bitcoin.org website?  This site is the centralized location that a large percentage of users get the link to download the bitcoin Satoshi client. What kind of security measures take place at bitcoin.org and how do we know we can trust the people who run the site?  Maybe the same government entity will take over bitcoin.org.

It is categorically different.   I can tell you my wallet encryption key but that does you no good unless you've also compromised my system or my paper backups to steal the wallet / seed (in the case of electrum).  This is two factor security.

What third party sources? It's not your fault that they don't practically exist, but it's still the case.

A major point I was making is that the theoretical security of a pragmatic user does not reduce the _systemic_ risk of a widely used service.  The fact that if users jump through some hoops that almost no users do they can personally be secure doesn't prevent the shared fate that we get from many people using a single point of failure.

I think it's quite trivial to profit from false payments though perhaps harder to profit from them on a wide scale.  In the context of Mywallet I'd probably use the mixer service to skim off users funds. People making regular transactions are prompted to participate in the mixer, and I'd simply have that skim off their inputs and repay them with fake ones.

I'd looked at the security page— It's platitudes and standard practices. While I'm glad that you have better security practices than some Bitcoin sites. Nowhere are the "these" concerns— the specific architectural limitations— discussed on it.  The stack exchange answer is much better, and some of that should make its way into the security page.

Hm. Did the email backup behavior change at some point? It makes me much happier to know it's a default.

Again, wrt your comparison with other clients my concern is what does individual things better (and indeed, your site does many things quite nicely!) but what creates systemic risk.  If a single person loses their wallet it is unfortunate but it is not catastrophic for the system. If a service depended on by tens of thousands of people merely goes _offline_ for an extended period thats terrible and if data is lost its catastrophic.  This is the cost of centralization: it creates failure modes which _must not happen_ and so defending against them is much more important.


Sadly, this is a worthless assurance. If your systems are compromised you wouldn't know about the logging.  It seems inevitable that you will be subject to law enforcement order to log some things (with or without due process, or whatever mockery of it you have in your location) and those orders will likely order you not to disclose this fact.   You could also be lying— you are, in fact— the best know enemy to casual privacy in bitcoin with the "first relayed" method; though I trust you are not but trust is what creates fiasco like mybitcoin, pirate, and bitcoinica. Plenty of people mine and do OTC exchanges.  Again, my concern is primarily systemic risk— and yes, the bitcoin exchanges are a systemic risk.  But one bad does not make a second bad irrelevant.

Please understand that I have great respect for the work you've done. Your service is very well constructed and well loved for good reason.  While some of the things I've brought up might be improved with some tweaks here and there, much of it is simply the structural consequences of centralized services, trusted parties, web clients, etc.   Those limitations don't reflect on your character or capability.   And they aren't flaws that exist in a vacuum: distributed solutions are harder to develop, harder to test, harder to add features to, often slower, often less reliable on average (though far more reliable in the worst case),  and darn near impossible to monetize in order to fund the maintenance and development.

There are plenty of reasons to use your service in spite of its limitations, but the benefits and limitations should be understood in context... and I don't think our community should take any actions which promote centralization or consolidation due to systemic risk if nothing else— so just like Bitcoin.org doesn't link to MTGOX (though it's also a widely love, well maintained, and very widely used service) I don't believe it should promote your wallet service either.

I can only speak of the chrome extension now but maybe this applies for other browser addons too.
Installing the chrome extension from the webstore introduces new attack vectors. Due to the silent and automatic update system of webstore extensions it is trivial to steal Bitcoins for:
- Hackers who manage to steal your Google Account
- Google employees
- Hackers who hack into Chrome Webstore/Google

This could be easily avoided by a standalone crx extension which does not autoupdate itself silently.  I really love My Wallet but advertising the webstore extension is definitely an issue.

Isn't MPEx a website? gmaxwell's point 0 is completely unavoidable for anything web-based.

Obviously none of those apply to MPEx (which DOES work as a wallet, among many other things it does for which it is much more famous).

This concern is valid. I'm not sure what you mean by the software changes all the time but the browser extension to mitigate this risk (https://blockchain.info/wallet/verifier) has not been updated in several months. The iPhone/android apps are not vulnerable to this. This will be solved in time by using keys split between the native apps and the web app.


Yes the responsibility is with the user to choose a secure password which is no different than any client offering wallet encryption. We do enforce a minimum password length of 10 characters and try and detect weak passwords on sign up.


Fairly easy to verify using 3rd party sources. Difficult for the server operator or hacker to profit from deceiving users in this manner.


https://blockchain.info/wallet/technical-faq
https://blockchain.info/wallet/security
https://blockchain.info/wallet/anonymity
http://bitcoin.stackexchange.com/questions/5249/how-secure-is-blockchain-info/5255#5255


Email backups are enabled by default. Wallets are backed up server side in multiple locations including Amazon S3. The average user probably cannot be trusted to make their own backups regardless of what client they are using. On every login the options to backup are clearly presented, Bitcoin-Qt does not provide any backup instructions or recommendations.


No requests are logged apart from unexpected error responses. The same logging is possible with electrum servers but in that case it might not be known who is running the servers or their privacy policies. As for running a full node, multiple entities are probably monitoring the bitcoin network itself using the "first relayed" method and IP loggers. Besides the biggest weakness to the anonymity of bitcoin is at the time of exchange not whether your ip address leaks.

I think if plugins such as NoScript (for FF and other Mozilla browsers) were to have an option for verifying SHA256 hashes of specific .js scripts then this would provide a significant improvement in DHTML security (such a feature would be of great help for my own software system that encrypts dynamic content using AJAX style requests over plain HTTP).

I actually think that the light gui version of electrum comes very close to that.

It was about 6 months ago ... probably time for retesting it.

Out of curiosity, how long is it? As far as I can say, Electrum greatly improved in recent versions.

Wow, I didn't except an answer of this depth, thanks.

I'll still be promoting it myself, because I believe the above drawbacks are all better than Users:

1. Failing to get started because of their fear of downloading software
2. Losing their wallets.

My Wallet can be improved so almost no wallets are lost:
1. email can be made opt-out (need to check a checkbox that says "I choose to open an account without giving an email address, I understand my wallet won't be backed up)
2. password complexity checks can be implemented

When thin Electrum-style clients are feature-rich and mature enough, perhaps they will be the best compromise. The last time I tried to use Electrum, I failed. The Bitcoin client is, as we all know, not usable yet by the general population (Gavin's grandma).

My largest technically oriented concerns would be:

(0) The software can silently be replaced with malicious copies that redirect funds or steal keys.  There exists JS pinning plugins for browsers but they aren't practically usable (the software changes all the time), and even if they were the systematic exposure I'm concerned about here isn't answered by it being possible for a savvy to make secure, to prevent disaster it must be secure by default.

(1) A significant fraction of users use insecure passwords which a hacker could attack. While it's possible for users to secure themselves, experience shows that even savvy people are remarkably bad at choosing passwords, and the systemic concern means that its a disaster for the bitcoin ecosystem even if 'only' the weak users are compromised so long as there are a lot of them.   This factor is in tension with the fact that unlike virtually all other webservices its not possible for the operator to recover a lost password if it was strong (this is also true of other clients, but I worry that the expectations for a website may be even more strongly in favor of recovery).

(2) Even without any modification to the client software a server compromise could result in users seeing confirmed payments which were never made (and never even possible— e.g. the attacker paid you 30 million bitcoin), this is doubly bad because there is effectively no second source for clientless user to check even if they were very paranoid.  Likewise, a malicious server could trick client into sending most of their funds to fees.   E.g. you have a 99 BTC input and want to spend 1 BTC. The site claims that the input has a value of 1 BTC (and that you have a separate fake 98 BTC input). Your balance looks correct but when you author a transaction you create one that has 98 BTC in fees which the attacker could then sell to miners.  A malicious server can also hide transactions— but I think thats not that much of a concern.  

(2a) Nowhere on the site are these security complications explained. Many people read the advertising copy promoting encrypted wallets and think its absolutely as secure are running their own full node. Even a paranoid user would probably not know to take actions to protect themselves against these risks.

(3) If the site is shutdown without notice or has its data and backups (if they exist at all) destroyed a large fraction— I'd guess a super-majority— of their users would lose all of their funds. Like I mentioned above, the fact that users can enable an email backup only helps those who uses it. The ecosystem would be harmed if a substantial number of users didn't.    The fact that the site directly integrates a 'coin mixer' and gambling interfaces greatly increases my concern that it may be on the receiving end of unexpected regulatory interference.

(4) Use of the site degrades user's privacy relative to normal SPV and Full clients.  The site may currently be doing detailed logging of all operations and queries. A major privacy loss event would be harmful to the ecosystem. They may even be selling this information to the highest bidder.  Unfortunately, I believe it is impossible for them to prove that they aren't doing this even with auditing. This concern is heightened by the fact that it offers functionality specifically for concealing coin histories (both making it more likely that someone would want to intercept their traffic, and making people more likely to trust it with their privacy).

There is also a non-technical and more general concern that major services— especially ones with names like 'blockchain'— get equated with bitcoin itself. Its fortune is our fortune. If the site is used by most users and shut down the headlines might "Bitcoin shut down" or if we're fortunate "Bitcoin blockchain shut down".   This creates fragility which the community should try to avoid.

I think (1) and (3) can be improved with auditing and escrows, (2) can be improved to some extent by better software (e.g. making the web software more like electrum).  (0) is fundamental.  I don't think (0) can be acceptably fixed— doubly so because the SSL CA infrastructure is _not_ trustworthy, at least not against either state level agents or attacks netting more than a few thousand dollars return (Basically, anyone who can intercept HTTP to your server can buy a certificate in your name; and multiple CA's have been compromised and have also issued sub-CA certs to unspecified commercial entities).  See the cryptocat drama on the internet for evidence in the online security community that (0) is considered insoluble.