Criteria for inclusion of web wallets.

[ghost]

I'm seeing requests to add wallets, especially some of the newer M of N style wallets, but I'm concerned that both bitgo and greenaddress are deploying compressed javascript from their own servers. This means that we have to trust the wallet operator regardless of claims of M of N security.

I think we should assume that a wallet operator will be hacked (from inside or out) and then we asses the impact of this on the user base. For example...

1. Coinbase, They have access to all funds, and therefore the impact is 100%.
2. Blockchain.info, Doesn't have access to all funds. They could steal funds from users as they login, this would be discovered fairly quickly by the community and the likely impact would be less than 1% of users impacted.

The new M of N style wallets are claiming higher security than blockchain.info, however this is not the case. All the wallets I looked at are deploying compressed javascript from their own servers. This makes it difficult to detect if they are working honestly (I am sure they are with the wallets mentioned above but why take the risk.)

So perhaps we should outline the criteria for wallet inclusion and then implementers can meet or exceed that criteria.

Something like...

1. At least 1 Year in operation.
2. All javascript in plain text and easy to read.
3. Javascript deployed from source control i.e. github. Not from private servers.
4. An integrity checker tool. Similar to the one blockchain already has.
5. No private keys stored on the server.
6. Disallow users from using email/password as login. Users will use the same email password combination with other services and will have there coins stolen that way.
7. A way for users to recover their wallet if the operator goes away. Recovery procedure should be quick and simple.

I'd be interested in hearing other peoples thoughts.

[saivann]

@carbonwallet Thanks for starting this discussion and for making concrete suggestions (let's see if any rough consensus can emerge from there). I'm interested in hearing other peoples thoughts as well. I'd personally like to add that web wallets owners' identity should be public, for minimum accountability (and recourse for the user).

[mbelshe]

Hey @carbonwallet - Thanks for checking this out.

I don't think wallet creators (including me or carbonwallet) should be part of defining criteria for inclusion in the list, especially retroactively. However, I do think it is fair that any wallet reply to inquiries about how bitcoins are kept safe with that wallet. To that end, here are a few qualifying points, which I hope do not sound defensive. I think all your questions are good ones.

a) Can you trust BitGo?
There are many reasons you can trust BitGo:
a) The owners/operators of BitGo are very public people with reputations you can evaluate. We're not here to steal your money, and if we do, you can haul us off to jail.
b) Security is a key tenant for BitGo. We offer M-of-N for a reason and were the first to build it as part of a comprehensive wallet security offering: https://bitgo.com/p2sh_safe_address
c) Never had a breach.
d) We do background checks on all employees.

b) What about modified JS from server hacks?
To clarify, this question is really "how does a user know if they're downloading authentic code?" This same problem exists for all wallets. Client-side wallets address this by using a secure hash or signature with the download. This works if the user checks it, but most users do not. It is also difficult (and worthless) to check after the initial download. (note also the recent attack with fraudulent PGP keys Gavin found)

BitGo's approach is to constantly monitor every key file which is part of BitGo constantly, from around the world. If any changes are made to any file, we're notified instantly, and shutdown the service. The user exposure here is very small, and I'd argue that this constant monitoring is actually a safer way to deliver secure software than client wallets.

c) What does BitGo do to secure it's servers?

1. Don't store keys. Architecturally, BitGo does not need to store your bitcoin in a big honey pot of coins. Users have the choice to let BitGo store zero or one encrypted keys on their behalf, and each user's bitcoin is stored in separate addresses controlled only by that user. This makes BitGo much less attractive to hackers already.
2. Operational lockdown. Everyone says they have this, but we really do. The servers are simply not accessible via ssh or any means on the outside network. Multiple airgaps are used between subsystems, all data-at-rest is encrypted, and all data-in-motion is sent over TLS.
3. Open Source. The key parts of BitGo are already open source, and we are committed open source going forward.
4. CSP. Content-Security-Policy is a browser-enforced whitelist of allowed JS. In addition to other common XSS-prevention techniques, this provides a whitelist across the whole site.
5. Audited. We hired an external auditor to audit the entire site, client and server side. All recommendations from the audit have been implemented. We will do another audit this year as well.
6. Constant monitoring. We use monitors which check for changes in JS constantly. If any file changes at any time, we instantly shutdown.
7. Much more. I've enumerated a few items, feel free to ask questions if you have more.

d) Is M-of-N more secure than single key systems like blockchain.info?
Absolutely. With single-key systems, any user that has malware infecting their client machine can have their key stolen while they access their wallet. With a M-of-N system, this is not possible.

e) Is it less secure to store 1 key on the server for a M-of-N system?
No, it is not less secure, it is more secure. First, with single key systems, stealing bitcoin only requires 1 key. With M-of-N, where M is greater than 1 and the server only holds 1 key, at worst, it is the same level of security. But at best, it is far superior. The reason is because the server can implement policies on behalf of the user which add additional protections to your bitcoin. For instance, BitGo servers can know that you're a user in the SF Bay Area. If someone does manage to get your passwords and 2FA and tries to transact on your account from Russia, we can refuse to sign (whitelisted IPs are also possible). Second, we can (and do) implement spending limits. You may have 10000 BTC stored with BitGo, but configure BitGo to only spend up to 10BTC per day. Like your ATM's daily limit, this mitigates your risk in the event of something going wrong. Single key systems simply cannot do this.

f) Regarding disallowing of username/password.
There are many ways to enforce user authentication, and disallowing usernames/passwords is definitely not the only way. Further, this must be balanced against users forgetting their passwords. Losing passwords is just as common, if not more common than getting hacked.

Nonetheless, BitGo uses a heavy duty system here which is not "disallow", but hopefully more advanced than it seems on the surface. We use two passwords, one for login and one for making transactions, and both use 2-factor-auth on top of that. The reason for separating these two is for two reasons. First, it allows us to enforce much stronger passwords on transactions than we do for login. (Try it and let us know what you think!) But the second reason is to make phishing attacks much more difficult. With a single password/2FA system, the phisher lures the user to a site, collects credentials, and then runs off to the origin site to steal bitcoin (coinbase has fallen prey to this). With the BitGo system, the phisher must lure the user to the phished site, steal the login/password/2FA, then lure the user into making a transaction (much harder), and steal a second set of credentials. This is a very complex and active (not passive) attack.

g) Recovery.
BitGo has built recovery tools, and they have been used already by real users. First, if you forget your passcode for your encrypted key, you can recover using your backup key created during account creation: https://www.bitgo.com/recoveraccount - this has been used many times succesfully by real users that forgot their secure passwords. Second, if BitGo goes down, you can use the tool at htttps://github.com/BitGo to recover the funds. This is more cumbersome, but it does work and a couple of users have actually audited it for us already. We plan to make it a little easier to use, but because its really for disaster recovery, it is okay for it to be a bit techie (only geeks know what github is anyway).

[ghost]

I hope the following is taken as constructive as that is the way it was intended.

b) What about modified JS from server hacks?

Although it's good you are monitoring your own JS and files, it would be even better if those files were available to the community for peer review and inspection. This wouldn't impact the quality of what you currently deliver.

If a user is able to install a wallet checker locally, he can be sure that no-one has interfered with that javascript since it left your servers. i.e. Cloudflare.

If a user has this facility, then I would agree we are more secure than the flat clients.

d) Is M-of-N more secure than single key systems like blockchain.info?

Correct me if I am wrong but if a users system is infected with Malware, the thief would be able to steal the BigGo email and password logon details. They would then be able to send Bitcoin from that account.

Your proposals for limits and policies would give added security, but as far as I can see you don't have those policies at the moment.

I believe 2FA gives more security against Malware and you don’t currently have that as far as I can see either.

So I think my list stands. I think the next slot for a web wallet should go to the most secure web wallet we can possibly make. And if that web wallet doesn’t exist yet, then we need to build it.

I will update my list, and hope for more feedback.

1. At least 1 Year in operation. Owners fully disclosed on the website.
2. All javascript in plain text and easy to read.
3. Javascript deployed from source control i.e. github. Not from private servers.
4. An integrity checker tool. Similar to the one blockchain already has. That can fully verify all client code against a public repository.
5. No naked private keys stored on the server.
6. Enable 2FA by default, or at least be very persuasive.
7. A way for users to recover their wallet if the operator goes away. Recovery procedure should be quick and simple. i.e. electrum passphrase.
8. Logins should time out or present a captcha after repeated login attempts.

[mikehearn]

Also see my comments on the BitGo pull req.

I think we should avoid, for now, trying to constantly raise the bar any time new wallets are submitted. If there is going to be an equivalent for the SSL "Baseline Requirements" in the Bitcoin wallet world, it needs to a hell of a lot more formal than random things thought up by random people on a pull request. The SSL BR's are phased in with many months of notice to allow the CA's (all of which have full time employees) time to adapt. There's also a voting process where the CA's (wallet authors in this case) can take part.

BitGo is a more advanced web wallet than what has come so far. For that reason alone, it should go in. We should not start requiring threshold signing of updates until there's a real infrastructure for that in place and most wallets have already adopted it, at that point, requiring recommended wallets to meet existing best practices would be reasonable, but inventing "best practices" that nobody actually practices is not.

So from me: let's put BitGo up on that page. Actually I'd like to see a more advanced page there that does a better job of promoting different wallets other than MultiBit and Bitcoin Wallet, even though they're based on my code and it's quite nice to have lots of users ;) But that's a topic for a different issue/pullreq.

[saivann]

@mikehearn Any opinion on Greenaddress?

Agreed on not enforcing made up requirements, that was not my intention either. I am actually more interested in having (at least) very minimum requirements, and promoting attributes of each wallet more transparently. But that will be a separate pull request.

Re: formal process, I'm open to any suggestion on this.

[ghost]

@mikehearn BitGo is a more advanced web wallet than what has come so far.

I don't think it is more secure than anything that has come so far, and this is much more important.

For example, BitGo allows me to try multiple email/passwords without timing me out, even from the same IP address. This means any script kiddy can come along and run an email/password bot and open up users accounts. Big fail.

This is why we have to be very careful with which wallets get promoted. Blockchain and Coinbase have already cut their teeth.

However, I would be happy to contribute to base line requirements for wallets.

[mbelshe]

@carbonwallet I don't really want to get into a he-said/she-said here (especially since we're both wallet makers). Please contact me offline and we can hash through any concerns you have before factually incorrect statements are made here.

To correct a couple of statements:

First, 2FA is required for all accounts that have wallets. We setup the 2FA when you create your wallet, not when you create your login, so you may not have seen it.

Second, we do lock you out after 20 tries on the 2FA. If you don't have a wallet with any money in it, the security requirements are lower. This is our way of helping the user gradually step into higher security as they get deeper into bitcoin and need it.

[ghost]

@mbelshe I see, apologies for jumping the gun.

[saivann]

Closing this issue as it has been addressed differently by the new page layout (by transparently displaying good and bad attributes of each wallets).