Revisit blockchain.info listing #663
Conversation
(For issues with transparency, bugs, and security of passwords and backups)
|
I strongly agree with this decision.
It's debatable if this change is actually of any value at this point in time to any users who signed up before this change was made. BC.i makes aggressive, incremental backups of users wallets onto their own host. Due to them not rotating keys or using change addresses, the compromise of any one of the users backups in the past will compromise the present one. They have not yet published any warning that every user should be making a new wallet and sending their funds there. As for the actual change, people have been telling them to do this for years without result. In addition to the concerns you have made:
This service should not be promoted on bitcoin.org. |
|
ACK |
|
Thanks, I really appreciate the time you've spent investigating these issues and providing clear information. Given the above, I have added an additional commit to replace more links to blockchain.info (block chain size - not necessary, and mining pools size - replaced by http://mempool.info/pools). |
|
Please wait for my comments early next week. |
|
@zootreeves Thanks for commenting. By "next week" you mean the first week of December? This pull req is currently scheduled for merging on December 6th. |
|
Yes, before the 6th. Just a quick note. The new android repo is available at https://github.com/blockchain/Android-Wallet-2-App the old repo is not longer being updated. |
|
@saivann @yah4Ua5b That's some great research you've both done! Although I'm on the "BC.i should be delisted" side of the fence (at least in the short term), to be fair there are a few critiques that I don't entirely agree with. In no particular order:
Here is an incomplete selection of various wallets' key stretching, for reference (mostly off the top of my head, so some details are probably wrong): Good key stretching
Somewhere in the middle
Weak key stretching
BC.i wallets are the only ones regularly stored in an online centralized service, so arguably it should be at least as strong as any other (it's not), although both of the Android wallets encourage online backups despite their weak key stretching...
Although I agree with the sentiment, I think the criteria for including on the choose-your-wallet page should reflect the default for new users, since that page is targeted to new users of a service. I'd certainly feel much better if the iteration count were upgraded as old users logged in, though (is it?).
Mostly agree, their 2FA is not effective against malware, although their model does prevent third party access to the encrypted wallets.
Most wallets still do not (or am I mistaken?)
I was under the impression that this tool existed to notify admins that their production servers had been tampered with. If this tool were hosted separately from BC.i's production servers, I disagree that the tool offers no value. Given that both the BC.i site and this tool are hosted behind Cloudflare, it's hard to say if this is the case...
Agree, although it's no different from any other checkFailTransparencyRemote wallet. Regardless of the above, I still agree they should be re-evaluated based on the same standards as any other new wallet. |
|
@gurnec Thanks a lot for your research on current state of key stretching! I am also interested to know if the iteration count will be upgraded as old users log in (and all previous copies erased). That doesn't make the mistake disappear, but is still a step in the right direction. |
|
Excellent. Thank you. Strong ACK, for what it's worth. The amount of effort their problems have put on the community to explain things to new users and try to keep them safe has been.. significant. |
So does the fact that the "username" is a completely random GUID. There's no situation in which that could be guessed, so the user already has to have had their information compromised for the 2FA to have any effect at all. It's an extremely narrow possibility for saving a user (compromised GUID, compromised password, not compromised wallet file).
BreadWallet, Bitcoin Core, Electrum 2, Trezor, GreenAddress, anything BitcoinJ based and any web based service running the bitcoinjs 1.0 library all use deterministic signatures to reduce their vulnerability surface.
The nameservers for blockchain.com, blockchain.info, bitcoin.com and blockchain-status.com are the same. CloudFlare gives each new account signup a random pair of nameservers in order to uniquely identify that domain as being owned by a particular account. In this case they are all You can read more about this behavior on the CloudFlare blog. |
|
@yah4Ua5b Thanks for your insights.
That's a good point, assuming that the username is in fact random which I can't verify (although we're quibbling a bit here here, I already agree that the most important feature of 2FA for bitcoin wallets is ineffective for BC.i's 2FA).
I (happily) stand corrected, thank you. (It somehow escaped me that ossl added this well over a year ago.) |
|
I disagree with this idea entirely. Blockchain.info is a great wallet and a great service and should be kept here. |
Dear god please don't push this, and let's try to erase the whole idea of relying on twelve-word passphrases from the community's memory forever. Mnemonic passphrases are horribly difficult to memorize, to the point that it's not even technically correct to call them "mnemonic" at all. See http://cups.cs.cmu.edu/soups/2012/proceedings/a7_Shay.pdf . Abstract:
I cited that and made some other arguments here https://blog.ethereum.org/2014/10/23/information-theoretic-account-secure-brainwallets/ about the right way to do brainwallet and password security; if BCI were to implement ultra-expensive outsourceable KDFs as described I would be a very happy cryptographer. My personal brainwallets have been safe for 2+ years, whereas my experience with mnemonic passphrases involves losing $1000 worth of storjcoin because I put the passphrase in a place where I ended up losing it. Aside from this, good points. With their recent $30m investment, I hope that BCI spends some money on top-notch security firms to look over their code. |
You're cherry picking an irrelevant point of the quote, the real takeaway is that they allow tragically weak passwords and until very recently proclaimed that they would take millions of years to break. Memorizing BIP39 seeds has never been a credible idea in the first place, it's much more use to think of them as easier encoding for transfer of information rather than anything else. BIP39 encoded BIP38 seeds are for disaster recovery rather than general every day use, so it would be utterly foolish to expect people to remember something so infrequently used. Confusingly Blockchain.info also offer a "recovery phrase" in the same style as a BIP39 seed, but it's a custom encoding of their GUID and password instead of a cryptographic seed.
Your inability to retain valuable pieces of paper doesn't really have any bearing on their utility. |
|
ACK, blockchain.info would really need a complete rewrite/redesign to be something we should recommend. Insisting that it meets the current standards for the page (which are currently much more lenient than they ideally would be) is only reasonable. |
I'm pointing out a part of the quote that I wanted to nitpick on because it's something that gets used way too much and has many misconceptions around it. I fully agree that memorized passwords require a strong level of keystretching to work well, perhaps even so strong that something like outsourceable strong KDFs would be needed to achieve high usability in javascript, and I agree with the other parts of the suggestion.
I could say the same thing about others' inability to remember information. People are different and all that :) |
|
I agree. Don't sacrifice security. |
|
ACK. They should be allowed to re-apply and make their case from the ground up, hopefully with improvements in tow. Strong NACK to pushing brain wallets of any sort. Public can not evaluate what good entropy is. |
|
ACK, BCI has consistently failed users. |
|
@vbuterin Assuming long passwords and "random mnemonics" are both as hard to remember, the point of my suggestion is that the later is truly random. Humans are inherently bad at producing true random passwords. Isn't that an efficient step forward for strenghtening passwords? |
|
ACK |
|
Long passwords are much easier to remember than random mnemonics, because Now, can mnemonic technology get substantially better, to the point where |
|
@vbuterin Should users be encouraged to only memorize passwords to begin with? Our brain is terrible at keeping information safe, especially if this information isn't used for a certain period of time. Random passphrase generators seem to lead people to printing their passphrase, as well as preventing people to use weak passwords in the first place. Although I agree that it's possible to generate strong passwords by yourself, my point being, I think it's safe to assume most users won't. I don't want to make this specific point a blocking issue though, but blockchain.info being a general audience wallet, it seems to me that assuming the user must be knowledgeable enough to come up with strong passwords against bruteforce attacks by themselves is not the best idea. Especially since blockchain.info looks like any other website in which you could use much weaker passwords without issue. |
So first of all, you need to decide: what kind of service are you looking If you want a BCI-type solution where BCI maintains encrypted wallets where
There we go, centralized-server-quality rate limiting while maintaining Access control is just one of those areas where multiheuristic approaches |
|
ACK Also I recommend stating for the record we intend to apply these same principles to all the services offered at bitcoin.org. (Great entropy discussion @vbuterin. I don't really write on things; just thinking about them usually consumes most of my time. But if I was smart enough to do both, I'd write something similar. (The KDF / blinding / multi-connection Tor idea is new to me, and will enjoy looking at it further.) I've tried many ways, and spent considerable time experimenting with different methods. In addition to your listed methods, for really high-value storage, I also make use of a personal, fairly simple substitution cipher for any "real" words in the passphrase. Began this with TrueCrypt years ago. I haven't tried to quantify it in terms of bits, but it allows me to create a significant entropy differential in my passphrases if need be, for what resembles a time-memory tradeoff. Demands less memory, but takes more time to perform the encode at pass entry.) Anyway, re: BCi, I very much hope they take this and fix it. I've been warning against them in greater strength since last January—specifically, that it was only a matter of time before email became the "simplest" attack vector, and to use true 2FA on it. I also pushed people to use the trick where you can create a new BCi wallet without an email, eliminating the obvious (to me & others, but not enough people) weakest link. All this said, Heartbleed is what changed all this. Passwords were leaked, and everyone reuses, myself included. Many users did not change them. In BCi's case, they had all the same information I have, plus $30M to pay security experts, and they did nothing to fix this glaringly-obvious disaster-in-waiting. In fact, all progress from the team is pretty glacial. Sorry, BCi, ACK, ACK, ACK. |
|
Anyway, let's move the discussion of entropy and password memorization On Wed, Dec 3, 2014 at 4:22 PM, FnxTX notifications@github.com wrote:
|
|
@vbuterin Yes, thanks for your comments, I will edit my first post given that there's no easy consensus on this one. |
|
@vbuterin
It's hard to give any particular wallet software a totally unanimous tick, but it's certainly desirable to make a point of what is ideal and what has flaws. The website currently lists things such as how vulnerable the environment the wallet operates in, how old the service is, who controls what and other key metrics.
This pull request is just an extension of that process, saying that the Blockchain.info service has too many flaws that have existed for too long for it to be considered acceptable for promotion. |
|
@saivann I have to say it doesn't seem like an overly fair process when competing wallet developers and anonymous accounts are allowed to vote on an issue, for which there are no guidelines, for a website that is supposed to be a neutral 3rd party. Nevertheless we respect the decision and will re-submit when permitted. I would like to reiterate that our view that a limited number of problems posted on Reddit (30<) in a year, should be weighed against the context of our wallet's popularity. We have a millions of accounts and hundreds of thousands of monthly logins. Instead of evaluating these issues contextually, it seems most here want to consider it in a vacuum without context. How many users have (often famously) lost very significant sums of money when using desktop clients due to malware, password issues and computer error? We could add them up but it would be thousands of coins at the very least. Perhaps you should consider starting a pull request to remove those as well and all trust hosted wallets to sign our transactions. KDFWe will discuss this internally. SharedcoinSharedcoin was purposely designed to try and fix the problem with coinjoin only being able to send fixed denominations. A system where you cannot accurately send fractional amounts doesn't seem very practical in the real world to me. "Sorry you can't pay for this, its not rounded to the nearest 0.1 BTC". If everyone took the first proposal of an idea as the de-facto and only way to implement something innovation wouldn't happen. We take the view that it is better to release useful products, iterate, and improve, than it is to stay solely in the clouds discussing hypothetical perfect solutions. A quick example to illustrate how sharedcoin solves the none identical output size problem:
I installed Dark Wallet to test their implementation. Firstly the software let me use the password 00000000 with no warnings. I deposited ~1.2 BTC waited 6 confirmations and tried to send it back to my original bc.i wallet. FYI I waited 2 hours for the transaction to send before giving up. When there are practical working implementations of trustless/low trust mixing then perhaps sharedcoin should be criticised more harshly. Instead the "my solution, which doesn't work, is better" crowd butts into every discussion and the echo chamber parrots it until it becomes gospel. Automatic email backupsI'm not sure about this, if it is the case it will be rectified in the next update. TransparencyAgain we will discuss release tagging internally and consider it going forward. |
|
@zootreeves DarkWallet is not even released and still alpha, not does it have a big mixing network because it's not released stable - so it's not fair to bring it into the discussion at all. SharedCoin is an abortion, there is no other way of putting it. |
Just to be clear, the ACK/NACK process isn't the same as a yea/nay vote. ACKers not only express approval for a commit but also that they're willing to help deal with problems arising from the commit; NACKers not only express disapproval for a commit but also that they're more likely to leave the project if the commit gets merged. As such, the impact of ACKs and NACKs are heavily weighted towards those people who contribute to the project in meaningful ways, and a truly anonymous ACK/NACK has zero weight. (Although anonymous comments can still help inform people's decisions.) At least one of the "competing wallet developers" who has posted on this issue has done a significant amount of volunteer review work for the wallets section of this site, so his implicit ACK counts for a lot. As you can see from all the comments in this issue, we rely heavily on expert reviews from wallet developers to make sure we understand the issues correctly. To my mind, that enhances the neutrality of this site rather than weakening it. We'd love your help too, if you or one of your team members can spare an hour or two a week to review wallets.
I agree. In the separate issue #670 for discussing specific wallet-listing criteria, we already discussing focusing less on the existence of bugs and more on communication about bugs, the speed at which the bugs were fixed, and whether the wallet attempted to enhance its QA so that similar issues were less likely to recur. Please feel free to join that conversation.
Lots have---which is why we have a score that specifically describes that risk to users.
Every desktop wallet gets that same negative score. It should be noted that when we score BC.i using the same set of objective criteria we use to score every other wallet, BC.i ranks worse than nearly every other wallet. It seems to me that the main reason BC.i is being delisted is that it has few virtues and many problems.
The site @saivann linked to has a nifty illustration about how the inputs can be associated with the outputs because they are non-fixed values: Thank you again for taking the time to post a detailed response. I hope we can resolve the remaining issues and get BC.i relisted without too much fuss. |
|
@zootreeves Agreed that bitcoin.org should be demanding with other wallets as well. I will take your feedback into consideration to continue improving the process. Setting guidelines to evaluate wallets and doing all communications is no easy or pleasant task. In any case, BC.i is one of the wallets that received the most free visibility from bitcoin.org and if the announced changes are to be implemented as expected, it might not take so long before the wallet can be re-added. Thanks for your clarifications regarding BC.i's approach to CoinJoin with SharedCoin. My intention isn't to push a particular approach into BC.i but rather understand how BC.i deals with known issues in order to evaluate your approach and possibly test it in the future like other approachs. |
Revisit blockchain.info listing
I don't think that's acceptable when it comes to protecting users transactions. If people are entrusting their privacy to your service's abilities to keep them private, "better than nothing" really doesn't cut it. Many people are under the impression that your SharedCoin service is congruent to CoinJoin and is therefor iron clad protection from analysis or discovery. To that end, what sort of bounties would you be offering to anybody who can demonstrate they are able unmask a large portion of all SharedCoin transactions? 25 BTC, 50 BTC, 100BTC? You sound pretty sure that your techniques are infallible, so I don't imagine this will be a problem for you at all. |
|
Just a reminder. I think most discussion thus far have been reasonably civilized. In general I'd appreciate that the tone remains this way toward any wallet being reviewed to keep reasonable cooperation, although I understand the frustration that many may have. Sure, setting any such bounty and improving any issues found in all transparency is certainly the kind of thing that should be encouraged IMHO, and a responsible action to protecting BC.i users. |
|
Why isn't there a published set of criteria that wallets must adhere to in order to be included on the Bitcoin.org list? I emphatically support calling attention to security weaknesses in wallets, but I haven't personally seen the level of scrutiny contained in this thread applied across the board. |
|
@kristovatlas See #670 |
|
Just for the records, another epic fail from BC.i http://www.reddit.com/r/Bitcoin/comments/2onm5r/blockchaininfo_security_disclosure/ resulting in 250BTC of losses |
|
Note how blockchain.info's code review is so bad they can't even catch spelling mistakes, let alone RNG breaks: blockchain/unused-My-Wallet@98d5a7c BTW the stuff above about their CoinJoin implementation and DarkWallet's is bullshit; I'll respond to it when I get some free time. Hopefully they can do some research and correct themselves first... On 8 December 2014 16:53:39 GMT+00:00, "฿tcDrak" notifications@github.com wrote:
|
|
@petertodd I suppose Math.random() isn't secure PRNG, is it? |
|
@Kixunil I'm not a Javascript expert, but IIRC it's not. |
|
@Kixunil No, it's not. |
|
@petertodd @SomeoneWeird Thank you! It scares me that they even thought about using it. |
|
Disagree on the social level. They give users the private keys. They also communicate well on Github. It's not so bleak as you paint it from the social perspective. The only real issue is that they have an HD wallet, and the keys are only given to the main address, you have to generate the keys on an external tool, so that you know the keys to the random addresses that the wallet has created. But then again, name me another web wallet that gives you all the keys to all the HD addresses, in case you want to export to another wallet. Proposal: Talk to the devs on Github. Ask them to implement some features until some given date in 6 month or so. If not, then drop the wallet from the recommended list around that date ! Or put a clear warning in red around the wallet name. Bashing this major wallet is not good, if the people behind it are well intended. At least some warning or grace period is needed, if we want to eject the good people left and right. |
|
Way to revive a 3 year old thread :) |
|
Maybe yes to a revival, seen that thread on twitter recently. Did not see the dates, before reading. It's a reoccurring topic, when the situation changes. I think it's time to talk to the blockchain.info devs on Github maybe. The other recommended wallets are all aging. The Blockchain.info did upgrade to dome degree, so it might be a good time to revise the recommendation as: "use on your own risk or so", but at leas they give us the keys for export/back-up, unlike other wallets. The third party multisig wallets are recommended on bitcoin.org. What will happen to the multisig, when the company goes out of business in a bust ? Blockchain.info now has the 2F logins. The best ones in the space, where the one tab is doing the auth all automatically. The only issue is the HD keys to export. Example: In case you have the 1000 addresses in there, with 1 USD for each, then it's a problem, because they only provide the export key to the main address, when you export into the alternative or new wallet. Then again it might be an issue with all HD wallets. The first and main factor for a wallet recommendation should be the keys. If you can export / back-up the keys, then the web wallet is better than the one that does not allow such thing. Security is the next step to consider, or warn about. Maybe there is a need for the list of the wallets to warn/inform about. Like a list of the 10 major wallet provides, and what kind of down-sides they have, at the current date of the recommendation. |
|
Furthermore just looked at the Github of https://github.com/blockchain And the https://github.com/greenaddress Greenaddress.it is recommended on bitcoin.org, while the blockchain.com / or .info is not, while it has more active development. They seem to be polishing their shapeshift integration and the money making part of the wallet at the moment, which is OK and sustainable for a company that wants to make a profit. I would not recommend the blockchain.info V3 wallet blindly, but at least they offer the access to the keys and the 2F auth + blocking of people who want to brute-force the login. |
You recover using your backup keys... Every multisig service and wallet offers backup keys (2 of 3, user holds 2 so can always recover, or 2 of 2 with timelocked recovery transactions sent periodically via mail) |
Blockchain.info uses BIP-44 for key derivation, which is compatible with other wallets including Trezor. There are, of course, many tools online that can derive individual addresses from the master xpub. |
|
@Dorson You may or may not have noticed that this issue was closed over two years ago. |
Blockchain.info received a relaxed review by being in the first wallets added on bitcoin.org. For basic fairness with other wallets, I think it should be revisited with reasonable criterias at least as demanding as other wallets.
After some review and research, I have found several important issues summarized below.
Bugs and losses: BC.i has suffered from concerning issues during the past year (e.g. iOS denomination bug, weak key stretching, sizeable number of users losing funds, and more issues I haven't verified yet)
Backup/Password Security: BC.i hasn't adopted security features which are slowly becoming standard in other wallets (e.g. BIP32, random passphrases, backup on setup, rotating addresses, 2FA by default).
Transparency: Source code of the app has been reset or not updated repeatedly, making bitcoin.org often relay the false claim that the app is open-source.
To be fair, each of these issues would have blocked or delayed listing BC.i if the wallet was submitted today. Accordingly, I think the logical next step to incentivize security and reduce risks for the user is to raise the bar for BC.i like other wallets. I suggest 7 days for BC.i to review/comment the list of issues below (@zootreeves), then suspend BC.i listing for at least 60 days. After this period, the wallet could be re-submitted for review.
Note: This pull req is not for bashing BC.i, I know they are having a bad image lately and not interested to feed that. If anything, I hope this can give them an opportunity to show they can address these issues.
In the absence of critical feedback, this pull request will be merged on December 6th.
Some issues for which I think fixes would be reasonable in the future:
BC.i's security relies on strong passwords (way more than a custodial wallet due to bruteforce attacks), yet BC.i's wallets are stored online (BC.i, email, Google drive, dropbox) and:
BC.i does not remind or require the user to enable 2FA.
Edit: (Although it now appears that 2FA was almost no effect with the current security model - similarly to wallets on bitcoin.org using no third parties)
BC.i still has unpublished source code for their Android app (4.0.17 on Google play, 4.0.12 on GitHub).
Edit: (Same issue with the new repository, 4.0.17 on Google play, 4.0.15 on GitHub)
BC.i does not enable HSTS (seems to me this could be a simple change to reduce MITM attacks).
Edit: Blockchain.info implemented HSTS.
Some issues that may not meet future requirements:
The wallet does not rotate addresses.
The wallet does not uses BIP32 wallets.
Edit: The wallet does not uses deterministic ECDSA nonce (RFC6979).
Some issues that may require to be fixed to avoid downgrading the control score:
BC.i does not let the user backup and access their wallet offline.
BC.i does not encourage or tell the user to download or print a copy of their wallet during setup.
BC.i requires recurrent manual backup, and automated backups is not set by default.
(BIP32 again could fix those issues altogether)