Revisit blockchain.info listing

[saivann]

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:

• Don't use truly random mnemonic passphrase, instead rely on users' passwords known to be weak. Edit: (Although this suggestion might not be the good one, see @vbuterin comments below)
• Allow weak passwords such as 0000000000 - Edit: fixed
• Password strength warnings are optional (and blue) - Edit: fixed
• Password strength information makes false claims (126 years to crack 123456789123456789) - Edit: fixed
• It is unclear to me yet if the new key stretching is secure enough.

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)

[yah4Ua5b]

I strongly agree with this decision.

It is unclear to me yet if the new key stretching is secure enough.

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:

• BC.i has not disclosed security problems to their users as they have a moral obligation to.
  • For the life of the service their system used plaintext websockets as a fallback. This was never disclosed to their users. This could have allowed anybody to simulate payments, steal from wallets, possibly inject code back into the users browser. No advisory was issued.
  • Up until recently their website was serving over HTTP and not forcing the upgrade to SSL. No advisory was issued.
  • Bitzuma found the service to be storing private keys in the users browser history under some circumstances. No advisory was issued.
  • An unknown number of users lost an unknown amount of money to MITM attacks against the service. There's been some mildly acknowledgement of this with a .onion URL issued, but no direct advisory was issued by the company.
• They advertise their 2FA service as a vital security feature, but the security model they have chosen means it does not affect the encrypted wallet files, offering near zero protection for the user even if they do decide to enable it.
  • Not in the least intuitively to most users it is bypassed by the wallet files that were (until recently) emailed to all of their users. These files can also be found on Google Drive, Dropbox and on the users computers, wherever they chose to make their backups.
  • If a wallet file is stolen, enabling 2FA after the fact has no effect, as it would on a website like coinbase.com. In other services enabling 2FA prevents even a compromise where a malicious user have access to both the username and password. This is not obvious to a technical user and isn't explained.
• Their advertised in-wallet privacy service "Shared Coin" offered in absence of change addresses does not function as advertised.
  • As pointed out by Peter Todd, this service is broken and offers no privacy.
  • An advisory was published on their blog downplaying the impact as requiring a lot of statistical analysis to break and shouldn't be of a concern to people using it.
  • Users are offered to pay a 0.5% (default "donation") towards the development of a piece of software they are told is open source (it's full of binaries and hard coded to BC.i's servers, there's no way it could work out of their environment).
• BC.i are still not using RFC6979 deterministic ECDA nonces for signing. Even after losing money to weak nonce bugs in their implementation of transaction signatures, this has not changed. They repaid users affected by this, but haven't reduced the vulnerability surface of the code.
• In public comments they claim their wallet software is open source. The source code for the client side portion of their web wallet is on GitHub, but has no published license and is therefor not open source and can't be used in any other setting. Every piece of it is hard-coded to their API and endpoints and couldn't be used for any other purpose even if a sufficient license was granted.
• BC.i misrepresents their "trust-less" model, their comments and marketing material suggest to their customers that they have absolutely no control, knowledge or ability for malice when using the My Wallet service.
  • You trust them not to attack the password protected files, you trust their storage security, you trust them not to backdoor their source, you trust CloudFlare.
  • Recently they have made comments that suggest that their client-side JavaScript can be verified by a blockchain.info owned tool and is therefore verify-ably unmodifiable. This is misleading, as if they were compelled to put a backdoor in their distributed software it obviously wouldn't be detected by this tool either.
  • They are highly unlikely to do anything malicious due to their investments and the age of the service, but there's nothing stopping them being compelled by force or legal order to backdoor or otherwise compromise their service.

This service should not be promoted on bitcoin.org.

[SomeoneWeird]

ACK

[saivann]

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

[zootreeves]

Please wait for my comments early next week.

[saivann]

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

[zootreeves]

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.

[gurnec]

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

weak key stretching

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

• Armory: modified ROMix (a component of scrypt) 0.25s CPU time
• Bitcoin Core: PBKDF1 0.1s CPU time (~100,000x)
• MultiBit HD: scrypt w/default parameters (but unsalted)
• Hive for OS X: scrypt w/default parameters

Somewhere in the middle

• Blockchain.info: new default: PBKDF2 5,000x; old default: PBKDF2 10x

Weak key stretching

• Bitcoin Wallet for Android backups: EVP_BytesToKey 1x (which is == MD5 3x)
• Electrum 1.x: PBKDF1 2x
• KNC Wallet for Android backups: EVP_BytesToKey 1x (which is == MD5 3x)
• mSIGNA: custom SHA256 2x + EVP_BytesToKey 5x (which is == SHA1 15x)
• MultiBit Classic: EVP_BytesToKey 1x (which is == MD5 3x)

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

It's debatable if this [improved key stretching] is actually of any value at this point in time to any users who signed up before this change was made. ...

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

2FA service as a security feature, but the security model they have chosen means it does not affect the encrypted wallet files...

Mostly agree, their 2FA is not effective against malware, although their model does prevent third party access to the encrypted wallets.

BC.i are still not using RFC6979 deterministic ECDA nonces for signing

Most wallets still do not (or am I mistaken?)

javascript can be verified by a blockchain.info owned tool at http://blockchain-status.com/javascript_verifier

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

There's 100% trust in blockchain.info regardless

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.

[saivann]

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

[midnightmagic]

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.

[yah4Ua5b]

@gurnec

Mostly agree, their 2FA is not effective against malware, although their model does prevent third party access to the encrypted wallets.

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

Most wallets still do not [use RFC6979](or am I mistaken?)

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.

Given that both the BC.i site and this tool are hosted behind Cloudflare, it's hard to say if this is the case...

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 beth and jay, we can make the assumption that they are controlled by the same account.

You can read more about this behavior on the CloudFlare blog.

[gurnec]

@yah4Ua5b Thanks for your insights.

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.

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

Most wallets still do not use RFC6979 (or am I mistaken?)

BreadWallet, Bitcoin Core, ,,, [do support RFC6979].

I (happily) stand corrected, thank you. (It somehow escaped me that ossl added this well over a year ago.)

[saivann]

@yah4Ua5b @gurnec Thanks, your comments are very insightful, not only in the context of BC.i .

[ntom]

I disagree with this idea entirely. Blockchain.info is a great wallet and a great service and should be kept here.

[vbuterin]

Don't use truly random mnemonic passphrase, instead rely on users' passwords known to be weak.

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:

In a 1,476-participant online study, we explored the usability of 3- and 4-word system- assigned passphrases in comparison to system-assigned passwords composed of 5 to 6 random characters, and 8-character system-assigned pronounceable passwords. Contrary to expectations, sys- tem-assigned passphrases performed similarly to system-assigned passwords of similar entropy across the usability metrics we ex- amined. Passphrases and passwords were forgotten at similar rates, led to similar levels of user difficulty and annoyance, and were both written down by a majority of participants. However, passphrases took significantly longer for participants to enter, and appear to require error-correction to counteract entry mistakes. Passphrase usability did not seem to increase when we shrunk the dictionary from which words were chosen, reduced the number of words in a passphrase, or allowed users to change the order of words.

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.

[yah4Ua5b]

@vbuterin

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.

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.

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.

Your inability to retain valuable pieces of paper doesn't really have any bearing on their utility.

[luke-jr]

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.

[vbuterin]

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.

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.

Your inability to retain valuable pieces of paper doesn't really have any bearing on their utility.

I could say the same thing about others' inability to remember information. People are different and all that :)

[Kixunil]

I agree. Don't sacrifice security.

[instagibbs]

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.

[btcdrak]

ACK, BCI has consistently failed users.

[saivann]

@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?

[petertodd]

ACK

[vbuterin]

Long passwords are much easier to remember than random mnemonics, because
you came up with them yourself, and so you have the ability to build into
the password information in which you have an entropic advantage. The goal
is not truly random passwords; the goal is how to achieve 80 bits of
security with respect to attackers that don't particularly know you while
having the minimum possible amount of entropy to memorize from the point of
view of yourself (see my discussion of entropy differentials in the second
above linked article)

Now, can mnemonic technology get substantially better, to the point where
we can generate passwords that people can easily remember? Maybe. But
empirical evidence shows that 12-word combos certainly are not it, and so I
think it's fair to conclude that memorable password tech, while
theoretically promising, is far too early to even consider forcing people
to use one particular scheme at this point in time (if that will ever be a
good idea).

[saivann]

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

[vbuterin]

@vbuterin https://github.com/vbuterin Should users be encouraged to
only memorize passwords to begin with?

So first of all, you need to decide: what kind of service are you looking
to build? If you want a service that is pure and completely stateless, then
you're developing a password scheme, and so memorized is the better
approach - however, I do recommend hard KDFs and I think the ultrahard
outsourceable model should be properly implemented and tried. If you try to
force upon users a scheme that's not memorizable, then you might as well
make it explicitly not password based and introduce a concept of a wallet
file.

If you want a BCI-type solution where BCI maintains encrypted wallets where
users need only input relatively simple passwords, but BCI has no access to
the wallets itself (beyond the ability to easily crack passwords), then the
correct path is to develop a scheme that offers that functionality. A quick
draft out of my head is:

1. Let P1 = sha256(password + 1), P2 = sha256(password + 2).
2. User creates wallet = { keystore, nonce } and encrypts to create
   encwallet = { enc(keystore, P1), G * P2 }, which the user sends to BCI
3. BCI accepts messages of the form { wallet id, nonce, sig } where sig =
   sign(nonce, P2).
4. If BCI gets a message where verify(sig, G * P2) = true, then BCI sends
   the encwallet to the user to decrypt, otherwise BCI sends an error message
   and no encwallet
5. BCI accepts a maximum of 1 request per second per IP address

There we go, centralized-server-quality rate limiting while maintaining
BCI's trademark client-side trust free property.

Access control is just one of those areas where multiheuristic approaches
have proven to win the day. The "mnemonic" approach I dislike because it's
fundamentally dogmatic, leaving no room for memorization in the system at
all (since, as I said, mnemonics are actually incredibly hard to memorize,
so people will end up copying it down into a text file at which point it's
just another kind of desktop wallet), and because it denies users choice.

[FnxTX]

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.

[vbuterin]

Anyway, let's move the discussion of entropy and password memorization
theory to another thread, it is a very specific point I have a feeling
we're clogging things up a bit too much in a discussion meant to be about
whether or not to delist BCI :)

On Wed, Dec 3, 2014 at 4:22 PM, FnxTX notifications@github.com wrote:

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 https://github.com/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 hard KDF 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. Less memory, but 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.

—
Reply to this email directly or view it on GitHub
bitcoin#663 (comment).

[saivann]

@vbuterin Yes, thanks for your comments, I will edit my first post given that there's no easy consensus on this one.

[yah4Ua5b]

@vbuterin
Yes, thank you, should probably try and push this boat back on topic.

@FnxTX

Also I recommend stating for the record we intend to apply these same principles to all the services offered at bitcoin.org.

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.

[dabura667]

ACK

[zootreeves]

Enforcing 2FA on all wallets

Beginning this week all wallets with a verified email attached will be required to authorise every access attempt from unrecognised browser. This includes when logging in with the wallet identifier. Additional time based 2FA can be enabled at the user’s discretion. In order to enable this other changes had to take place as follows:

• The process for removing two factor authentication has been re-worked. Often our support agents did not have enough information available to determine the genuine owner of an account. The process is now fully automated with a waiting time of between 7 days - 1 month enforced depending on the level of security enabled on the account. If the request is malicious this gives time for the real wallet owner to come forward and block the request.
• Wallet API access must now be explicitly enabled for all new wallets. For all new wallets and existing wallets ip address accessing the wallet API must be whitelisted by the wallet owner.

SSL and HSTS

Up until recently we were not enforcing a https:// redirect on the homepage. The strategy instead was all links in the http version of a page to be replaced by https links at which point, when following a link, the users browser would receive the HSTS header. Of course both links and redirects can be altered by a MITM attacker and neither would have help with the recent problems with TOR exit nodes.

Today we are announcing that in 10 days time http:// requests on all endpoints will be 301 redirected to https://. We have also applied to have our certificates preloaded with chrome and firefox and into the HTTPs everywhere browser extension.

http://blog.blockchain.com/2014/12/04/important-announcement-for-blockchain-api-users/

TOR MITM Attacks

The majority of the recent reports of users funds being lost was due to user’s use of Tor. Users accessing their wallets via Tor were compromised by malicious exit nodes on the Tor network. We warned users about this, then blocked Tor. In the interim, we worked on a solution.

We have setup a new hidden service for TOR users who can now access the site without proxying traffic through exit nodes or cloudflare We are now the second service ever to have been issued a valid SSL certificate for a .onion domain. The service is available at https://blockchainbdgpzk.onion/

The certificate serves a verification function, so that users can be easily ensure they are actually accessing blockchain.info and are not being compromised.

Transparency

As I mentioned previously the source code for the Android app was moved to a new repository. In future we will make sure the repository is always kept up to date with the release version, I believe in this case the manifest file was out of date - this has now been corrected.

Reasons why KDF default was not Changed Sooner

• Due to Apple's old policy on Bitcoin apps, we were stuck with an iPhone app we were unable to update which was fixed at 10 KDF iterations. Changing the default without upgrading these users would have risked user’s being locked out. We weighed that risk against the relatively modest security gains of increasing the default KDF iteration setting and decided not to until we could update the iOS app and ensure capability. We did however enable it to be increased and recommend users do it via our blog.
• Our merchant API requires the server to decrypt the wallet every request. When serving just a couple of hundred API calls per second, key stretching starts becoming intensive. We have only just recently had the server capacity to support larger KDF iterations.
• We had allowed time to update all our wallet clients and apps including the iPhone app, Android app, Browser extensions, RPC api, Merchant API, Sharedcoin and Web interface. Not only did we have to update them but we had to give time for users to update as well.

The option has been available in Account Settings to increase the KDF iterations for a while and our new wallet format allows for changing of KDF iterations significantly easier. The new default will ensure existing users are upgraded next time they use their wallet. However if the user has chosen a weak password, the increase in KDF iterations only serves to delay a brute force attack and will not save them. Users who have chosen strong 12 character+ passwords are equally as secure with 10 iterations as they are with 5000; it just isn’t feasible to bruteforce. Unfortunately, due to the way our service works we cannot tell which wallets have weak passwords in order to issue warnings.

• The password strength meter on signup has been improved. The new recommendation for brute forcing “123456789123456789” is 2 hours. The mnemonic is not a random seed, it is simply to help the user remember their wallet identifier and password.

Disabling of Wallet Backups

Wallet backups are longer sent to the user’s address email by default and this option must be explicitly enabled in [Accounts Settings].

Sharedcoin

First let me say that Sharedcoin is a free service, the donation is entirely optional. It has also never been guaranteed to offer perfect anonymity. However, there has been no evidence offered or tool released to prove that the service is “broken.”

Having said that, we are working on improvements and will hopefully have these released by the end of the year. We don’t allow our users to change the Sharedcoin server from our default because it potentially opens security and privacy issues with 3rd parties. However, a competing wallet service is perfectly free to setup a Sharedcoin server for their own users.

BIP32 Support

Behind the scenes we have been working on a new BIP32 wallet which will be ready for public release early next year. The new wallet uses deterministic signatures as per RFC6979. We’ve also recently added support to the block explorer for looking up BIP44 extended public keys.

Closing Thoughts

When I designed the service almost 4 years ago it wasn’t designed to hand hold and perhaps we have failed on our duty to educate some users on how to use the service securely. We always have, and will continue to try to focus on educating users on how to securely and safely use our services and bitcoin generally. Balancing maintaining our users privacy, by not knowing much about them, while also trying to help them, is certainly a challenge.

However we are one of, if not, the oldest running and most popular web wallet service. Tens of thousands of users login everyday without issue and do tens of thousands of transactions - the issues you see from users on reddit are a tiny minority. We track trends in customer operations closely on our support desk and over the last year have made improvements across common issues.

Many of the comments reference our capital raise and disappointments with the use of its proceeds. I think it is worth pointing out that we closed the round about eight weeks ago now. We have only in the last few weeks even begun to deploy the capital at all. For the majority of our history, we were a bootstrapped company with a very finite amount of resources attempting to scale and provide a service as best we could to hundreds of thousands of users.

The improvements listed above as well as future improvements on the way soon will make the defaults significantly much more secure for both new bitcoin users and advanced users alike.

[harding]

@zootreeves I'm sure the other people on this thread will reply to your comment specifically, but I want to thank you immediately for providing such a detailed and thoughtful (and well formatted!) response to the concerns on this thread.

[btcdrak]

It's good for sure, but, it seems the only the only way to get BCI to sit up and take notice is "to put a gun to their head" metaphorically. Discontent with BCI runs deep. Chat with devs in IRC about BCI and how unreliable and buggy their services are. I would be inclined to suggest BCI is removed anyway and only added back once they have reformed.

[saivann]

Note; I suggest we ignore inflammatory comments and accusations from MillyBitcoin, or this thread will derail very soon. This user is supposed to be banned from the repository since months. Anyway, very positive news, I'll let others comment before commenting myself.

[schildbach]

It's good to hear bc.i finally moves after years of ignoring comments about safety. However, I suggest (re-)evaluating the listing of bc.i only on the status quo, rather than any promises.

[yah4Ua5b]

@schildbach @btcdrak

However, I suggest (re-)evaluating the listing of bc.i only on the status quo, rather than any promises.

Agreed. They should be evaluated on the security and privacy they currently offer, rather than the security and privacy they promise to offer some time in the future.

@zootreeves

We’ve also recently added support to the block explorer for looking up BIP44 extended public keys.

I urge you to reconsider that. Nobody should be promoting that users give their BIP44 public derivation keys to anybody as it gives third parties unlimited access to all of their past and future transactions. Even if your service does not monitor or log these keys, it sends a message to users that they can be happily sprayed around the internet without consequence.

[harding]

Upon reviewing our policy in the README and wallet template file (with English translation strings), I don't see any reason to delist BC.i based on the OP or comments in this PR.

That doesn't mean I oppose delisting---my emotions strongly say "delist"---but as far as I can tell, we don't have a written policy for rejecting or delisting any wallet for any reason. Instead we have a variety of scores which cover most situations---including (I think) BC.i's current status. It isn't clear to me why this PR is delisting BC.i rather than changing its score to reflect its current state.

If we're going to set a minimum standard, I think it should be a standard. We should have a document that says, "wallets that do X (or don't do Y) will not be listed." For example: wallets that don't have at least two good scores [such as BC.i right now] will not be listed.

To be clear: this is not a NACK. I don't mind if BC.i is removed. I'm just reserving my ACK for a situation where removal is warranted based on policy.

[petertodd]

BC.i's failure to recognise why SharedCoin is seriously broken and dangerous makes me even more confident in my strong-ACK for removal.

Right now we should be treating them as a brand new service with no track record at best, obvious grounds for removal until they build that solid track record.

On 4 December 2014 16:15:27 GMT+00:00, Ben Reeves notifications@github.com wrote:

Enforcing 2FA on all wallets

Beginning this week all wallets with a verified email attached will be
required to authorise every access attempt from unrecognised browser.
This includes when logging in with the wallet identifier. Additional
time based 2FA can be enabled at the user’s discretion. In order to
enable this other changes had to take place as follows:

• The process for removing two factor authentication has been
  re-worked. Often our support agents did not have enough information
  available to determine the genuine owner of an account. The process is
  now fully automated with a waiting time of between 7 days - 1 month
  enforced depending on the level of security enabled on the account. If
  the request is malicious this gives time for the real wallet owner to
  come forward and block the request.
• Wallet API access must now be explicitly enabled for all new wallets.
  For all new wallets and existing wallets ip address accessing the
  wallet API must be whitelisted by the wallet owner.

SSL and HSTS

Up until recently we were not enforcing a https:// redirect on the
homepage. The strategy instead was all links in the http version of a
page to be replaced by https links at which point, when following a
link, the users browser would receive the HSTS header. Of course both
links and redirects can be altered by a MITM attacker and neither would
have help with the recent problems with TOR exit nodes.

Today we are announcing that in 10 days time http:// requests on all
endpoints will be 301 redirected to https://. We have also applied to
have our certificates preloaded with chrome and firefox and into the
HTTPs everywhere browser extension.

http://blog.blockchain.com/2014/12/04/important-announcement-for-blockchain-api-users/

TOR MITM Attacks

The majority of the recent reports of users funds being lost was due to
user’s use of Tor. Users accessing their wallets via Tor were
compromised by malicious exit nodes on the Tor network. We warned users
about this, then blocked Tor. In the interim, we worked on a solution.

We have setup a new hidden service for TOR users who can now access the
site without proxying traffic through exit nodes or cloudflare We are
now the second service ever to have been issued a valid SSL certificate
for a .onion domain. The service is available at
https://blockchainbdgpzk.onion/

The certificate serves a verification function, so that users can be
easily ensure they are actually accessing blockchain.info and are not
being compromised.

Transparency

As I mentioned previously the source code for the Android app was moved
to a new repository. In future we will make sure the repository is
always kept up to date with the release version, I believe in this case
the manifest file was out of date - this has now been corrected.

Reasons why KDF default was not Changed Sooner

• Due to Apple's old policy on Bitcoin apps, we were stuck with an
  iPhone app we were unable to update which was fixed at 10 KDF
  iterations. Changing the default without upgrading these users would
  have risked user’s being locked out. We weighed that risk against the
  relatively modest security gains of increasing the default KDF
  iteration setting and decided not to until we could update the iOS app
  and ensure capability. We did however enable it to be increased and
  recommend users do it via our blog.
• Our merchant API requires the server to decrypt the wallet every
  request. When serving just a couple of hundred API calls per second,
  key stretching starts becoming intensive. We have only just recently
  had the server capacity to support larger KDF iterations.
• We had allowed time to update all our wallet clients and apps
  including the iPhone app, Android app, Browser extensions, RPC api,
  Merchant API, Sharedcoin and Web interface. Not only did we have to
  update them but we had to give time for users to update as well.

The option has been available in Account Settings to increase the KDF
iterations for a while and our new wallet format allows for changing of
KDF iterations significantly easier. The new default will ensure
existing users are upgraded next time they use their wallet. However if
the user has chosen a weak password, the increase in KDF iterations
only serves to delay a brute force attack and will not save them. Users
who have chosen strong 12 character+ passwords are equally as secure
with 10 iterations as they are with 5000; it just isn’t feasible to
bruteforce. Unfortunately, due to the way our service works we cannot
tell which wallets have weak passwords in order to issue warnings.

• The password strength meter on signup has been improved. The new
  recommendation for brute forcing “123456789123456789” is 2 hours. The
  mnemonic is not a random seed, it is simply to help the user remember
  their wallet identifier and password.

Disabling of Wallet Backups

Wallet backups are longer sent to the user’s address email by default
and this option must be explicitly enabled in [Accounts Settings].

Sharedcoin

First let me say that Sharedcoin is a free service, the donation is
entirely optional. It has also never been guaranteed to offer perfect
anonymity. However, there has been no evidence offered or tool released
to prove that the service is “broken.”

Having said that, we are working on improvements and will hopefully
have these released by the end of the year. We don’t allow our users
to change the Sharedcoin server from our default because it potentially
opens security and privacy issues with 3rd parties. However, a
competing wallet service is perfectly free to setup a Sharedcoin server
for their own users.

BIP32 Support

Behind the scenes we have been working on a new BIP32 wallet which will
be ready for public release early next year. The new wallet uses
deterministic signatures as per RFC6979. We’ve also recently added
support to the block explorer for looking up BIP44 extended public
keys.

Closing Thoughts

When I designed the service almost 4 years ago it wasn’t designed to
hand hold and perhaps we have failed on our duty to educate some users
on how to use the service securely. We always have, and will continue
to try to focus on educating users on how to securely and safely use
our services and bitcoin generally. Balancing maintaining our users
privacy, by not knowing much about them, while also trying to help
them, is certainly a challenge.

However we are one of, if not, the oldest running and most popular web
wallet service. Tens of thousands of users login everyday without
issue and do tens of thousands of transactions - the issues you see
from users on reddit are a tiny minority. We track trends in customer
operations closely on our support desk and over the last year have made
improvements across common issues.

Many of the comments reference our capital raise and disappointments
with the use of its proceeds. I think it is worth pointing out that we
closed the round about eight weeks ago now. We have only in the last
few weeks even begun to deploy the capital at all. For the majority of
our history, we were a bootstrapped company with a very finite amount
of resources attempting to scale and provide a service as best we could
to hundreds of thousands of users.

The improvements listed above as well as future improvements on the way
soon will make the defaults significantly much more secure for both new
bitcoin users and advanced users alike.

---

Reply to this email directly or view it on GitHub:
bitcoin#663 (comment)

[saivann]

@harding Indeed, nor any policy to accept any particular wallet actually..

I agree on the principle. If I haven't suggested any such standard is because I don't know how we could set a policy that would produce a clear yes/no answer while taking into account the varying severity, recurrence and number of issues, bugs or potential misrepresentations for any wallet, as well as the time for fixing these issues and the quality of the applied solutions. My impression is this would become inefficient bureaucracy or always end up being discussed here in every case.

I also tend to think it's good to engage wallet developers in these discussions so they can provide insights into their security model and potential new solutions. Every security model has drawbacks. The ultimate goal is to incentivize developers to innovate and care about security.

But FWIW, I think as soon as there's any indication that users have been harmed or could have been harmed by any issue in relation to any wallet, suspending a wallet should be easily considered.

[saivann]

Note; if the "standards for accepting / refusing wallets" becomes a discussion, I suggest opening a separate issue.

[bababooey22]

I have 62 wallets running for services of mine, thanks for putting a ton of work on me and forcing me to manually reset all settings.
What kind of mickey mouse programmer does that without even a warning first.

[bababooey22]

Also I have to manually enable the api every time I want to automatically create a new wallet,oh man you're killing me.

[millibitz]

@bababooey22 Using the same API code that created the wallet will allow you access through the wallet API.

[bombino]

ACK

[saivann]

It is very encouraging to see blockchain.info reacting promptly, this makes me more optimistic that the wallet can be re-added in the future. I have updated my initial post with fixes from BC.i .

This pull request received a lot of support thus far and the first rationale for this pull request being the previous track record of the service, this pull request is still scheduled for merging tomorrow - however I think discussions can continue afterwhile in case there is still useful exchanges, questions and feedback. I invite @zootreeves to re-submit the wallet after a temporary period of 60 days once the service has been re-designed with HD wallets support. I also wish to thank @zootreeves for answering every points and hope these improvements will also help prevent issues for BC.i in the future.

With regards to having more transparent standards for inclusion, I have opened pull request #670.

@zootreeves Some additional questions;

KDF:

Unfortunately, due to the way our service works we cannot tell which wallets have weak passwords in order to issue warnings.

Indeed, but isn't it possible to simply send an email to all users telling them to refresh their backup if they want to be sure that they're using a secure encryption?

Sharedcoin: This hasn't been re-tested recently to my knowledge, but it seems that the service was vulnerable to this technique and as previously outlined by Peter Todd, blockchain.info didn't generate identical outputs between participants, so this was an important weakness that could be fixed. Even if BC.i doesn't claim "perfect privacy", is there a good reason for BC.i to not address this issue? Or did BC.i actually fix this issue at some point?

Automatic email backups: Maybe I don't have the latest version, but the Android app still asks the user to enable that feature at each start. I guess according to your comments that you're planning to update this in a near future?

Transparency: Most wallets are tagging releases to facilitate reviewing changes in the code. This is also a requirement to get a good transparency score, so you may want to consider this simple additional step.

[bababooey22]

I really don't know why blockchain.info has to comply to this, the site is far more popular than the bitcoin site or whatever list they want to be on.

[SomeoneWeird]

@bababooey22 They don't. It's totally up to them.

[zootreeves]

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

KDF

We will discuss this internally.

Sharedcoin

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

• Alice Wants to send 1.245 BTC
• Bob Wants to send 1.576 BTC
• Alice's payment is split into two random outputs of 0.856 BTC and 0.389 BTC
• Bob's payment is split into two random outputs of 0.569 BTC and 1.007 BTC
• The sharedcoin server adds an output of 0.331 BTC, which in combination with alice's outputs sum to the same value as Bob's. In addition it adds a 0.676 BTC output to Bob's 0.569 BTC summing to the same total as alice's output.
• You are no longer able to distinguish between which outputs are Bob and which outputs are Alice's despite knowing the send value.

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 backups

I'm not sure about this, if it is the case it will be rectified in the next update.

Transparency

Again we will discuss release tagging internally and consider it going forward.

[btcdrak]

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

[harding]

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.

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

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.

How many users have (often famously) lost very significant sums of money when using desktop clients due to malware, password issues and computer error?

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.

You are no longer able to distinguish between which outputs are Bob and which outputs are Alice's despite knowing the send value.

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.

[saivann]

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

[yah4Ua5b]

@zootreeves

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.

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.

[saivann]

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.

[kristovatlas]

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.

[saivann]

@kristovatlas See bitcoin#670

[btcdrak]

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

[petertodd]

Note how blockchain.info's code review is so bad they can't even catch spelling mistakes, let alone RNG breaks: blockchain/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:

Just for the records, another epic fail from BC.i
http://www.reddit.com/r/Bitcoin/comments/2onm5r/blockchaininfo_security_disclosure/

---

Reply to this email directly or view it on GitHub:
bitcoin#663 (comment)

[Kixunil]

@petertodd I suppose Math.random() isn't secure PRNG, is it?

[petertodd]

@Kixunil I'm not a Javascript expert, but IIRC it's not.

[SomeoneWeird]

@Kixunil No, it's not.

[Kixunil]

@petertodd @SomeoneWeird Thank you! It scares me that they even thought about using it.

[Dorson]

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.

[SomeoneWeird]

Way to revive a 3 year old thread :)

[Dorson]

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.

[Dorson]

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.

[dabura667]

What will happen to the multisig, when the company goes out of business in a bust?

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)

[kristovatlas]

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.

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.

[crwatkins]

@Dorson You may or may not have noticed that this issue was closed over two years ago.
The best method to add a wallet to the listings is to submit a PR with screenshots and proposed scoring. The developer (or any interested third party) that is willing to support the listing and believes that the wallet meets our listing criteria is welcome to submit the PR.