Add Copay wallet

[bitjson]

Continuing from bitcoin#587.

[bitjson]

I made several updates related to adding Copay to bitcoin.org.

Added Copay

Copay has been added, platforms:

• Android
• iOS
• Windows Phone
• Mac
• Windows
• Linux
• Web

Mobile

Desktop

Web

One thing to note – Copay is no longer distributed as a remote web app, only as a chrome extension. I left it in the Web category, but I changed checkfailtransparencyremote to checkpasstransparencyopensource, as that seems to fit better. It might be worth clarifying the security benefit of extensions over websites in another pull request.

Added Windows Phone

Additional Classifications

Since Copay’s primary app makes it very simple for end users to use an alternative or self-hosted (open source) wallet node, I think it would be valuable to add a classification for wallets which enable the users to run their own nodes. I tried to stay as true to the other categories as possible, but I’d appreciate other thoughts on the below.

"Remote validation": checkfailvalidationremote

In an abundance of caution, since Copay’s validation uses a BitPay-hosted BWS server by default, I marked this as checkfail. Most users are not likely to host their own service, though the new txt makes it clear that this is possible:

Payments are validated by a remote node rather than the wallet itself. By default, this requires trust in the remote node to not hide or simulate payments. You can eliminate this requirement by connecting the wallet to a remote node you control. However, it is not as secure as a full node like Bitcoin Core.

Most of the language/style comes from existing classifications checkfailvalidationcentralized and checkpassvalidationservers.

"Discloses information to a remote node” : checkfailprivacydisclosureremote

Again, abundance of caution, since Copay uses a BitPay-hosted BWS server by default, I marked this as checkfail, but I think it's important to note that users have the option to implement very strong privacy by controlling their node.

By default, this wallet uses central servers which are able to associate your payments together, log your IP address, and retain records of metadeta your wallet shares with the node. To avoid leaking information, you can connect the wallet to a remote node you control.

Again most of the language/style comes from existing classifications checkfailprivacydisclosurecentralized and checkfailenvironmentdesktop

---

I'm removing the WIP tag from the subject, as I think this is in review stage now.

@harding, @matiu, and others interested, I’d appreciate any ideas you have to improve this pull request. Thanks!

[crwatkins]

@bitjson, Thanks for your updates, and thanks for taking the time to understand the scoring so well and make some excellently worded suggestions.

One thing to note – Copay is no longer distributed as a remote web app, only as a chrome extension. I left it in the Web category, but I changed checkfailtransparencyremote to checkpasstransparencyopensource, as that seems to fit better. It might be worth clarifying the security benefit of extensions over websites in another pull request.

We have been recently listing extensions in the desktop (not web) category and the issue was just discussed here #827 . A quick summary of my thoughts on the issue is that our web category is a selection criteria that users employ to find a wallet which they do not need to "install" on a computer (which they may not have control over).

Added Windows Phone

A welcome addition!

Since Copay’s primary app makes it very simple for end users to use an alternative or self-hosted (open source) wallet node, I think it would be valuable to add a classification for wallets which enable the users to run their own nodes. I tried to stay as true to the other categories as possible, but I’d appreciate other thoughts on the below.

I think you bring up an excellent point which we should address at some point. Scoring for self-run full nodes also came up here #878 . To summarize my thoughts in that thread: I support making some changes in this area eventually, but I would like to hold off adding more classifications until we step back and take a full holistic view of the classifications (and then go back to re-score all the wallets).

Also, as I recently mentioned in the MultiBit HD PR #887 :
In general, I'm hesitant to create new scoring or we are likely to approach as many scores as wallets. Each new wallet these days is innovative and has new features that don't fit every category perfectly, which regularly causes a new score to be suggested during review.

[crwatkins]

I have reviewed Copay based on the current wallet requirements criteria and my evaluation is below. The summary is that the wallet passes on security and overall design. However, because the website that links to executable code does not yet support HSTS and the website does not work with the Qualys SSL tester, I cannot at this time recommend it for listing. I am willing employ alternate SSL testing methods if there is a compelling reason why this testing tool won't work on copay.io. BitPay is working on these issues and I will be glad to recommend Copay for listing once these website issues are resolved.

Copay

Chrome app version v1.0.1

iOS app version v1.0.0

Android app version v1.0.1

Review version 20150602401

The wallet list is based on the personal evaluation of the maintainer(s) and regular contributors of this site, according to the criterias detailed below.

These requirements are meant to be updated and strengthened over time. Innovative wallets are exciting and encouraged, so if your wallet has a good reason for not following some of the rules below, please submit it anyway and we'll consider updating the rules.

Basic requirements:

• Sufficient users and/or developers feedback can be found without concerning issues, or independent security audit(s) is available

PASS This wallet has been well publicized for over a year without any current concerning issues.

• No indication that users have been harmed considerably by any issue in relation to the wallet

PASS No indication that users have been harmed.

NOTE Issues when users need help such as http://www.reddit.com/r/Bitcoin/comments/38sucy/funds_stuck_in_copay_2of3_wallet_need_help/ are addressed quickly.

• No indication that security issues have been concealed, ignored, or not addressed correctly in order to prevent new or similar issues from happening in the future

PASS A significant bug was found during beta http://blog.coinspect.co/copay-wallet-emptying-vulnerability that was quickly addressed.

• No indication that the wallet uses unstable or unsecure libraries

PASS Uses bitcore and sjcl

• No indication that changes to the code are not properly tested

PASS Tests are included in github and services are tested using mocha and karma.

• Wallet was publicly announced and released since at least 3 months

PASS This wallet has been in public beta with completely public issue tracking https://github.com/bitpay/copay/issues/ for over a year, so the 3 month requirement is waived.

• No concerning bug is found when testing the wallet

PASS The only concerning bug found during testing (regarding balance updates) was fixed bitpay/copay#2733 before being reported

• Website supports HTTPS and 301 redirects HTTP requests

PASS Redirects copay.io and www.copay.io

• SSL certificate passes Qualys SSL Labs SSL test

FAIL The Qualys tester actually fails on this site (i.e. copay.io does not fail the test, the test fails to run): Assessment failed: Failed to communicate with the secure server

NOTE An alternative set of tests may be constructed to satisfy this requirement

NOTE Other tests also fail:

curl 7.37.1 (x86_64-apple-darwin14.0) libcurl/7.37.1 SecureTransport zlib/1.2.5
% curl -i -k  https://copay.io
curl: (35) SSL peer handshake failed, the server most likely requires a client certificate to connect

• Website serving executable code or requiring authentication uses HSTS with a max-age of at least 180 days

FAIL No HSTS

• The identity of CEOs and/or developers is public

PASS https://bitpay.com/about

NOTE There is no reference to this on the copay.io site nor any reference to the BitPay site.

• If private keys or encryption keys are stored online:
  • Refuses weak passwords (short passwords and/or common passwords) used to secure access to any funds, or provides an aggressive account lock-out feature in response to failed login attempts along with a strict account recovery process.

N/A

• If user has no access over its private keys:

N/A User has full access over private keys

• Provides 2FA authentication feature
• Reminds the user to enable 2FA by email or in the main UI of the wallet
• User session is not persistent, or requires authentication for spending
• Provides account recovery feature
  • If user has exclusive access over its private keys:
• Allows backup of the wallet

PASS Allows backup from settings of a JSON formatted AES encrypted blob

NOTE Syntax of blob is not yet documented, so the only supported restore is with a working Copay wallet

• Restoring wallet from backup is working

PASS Wallets can be restored (and cloned) using the backup blob

NOTE Bitpay is working on a standalone sweep tool http://www.reddit.com/r/Bitcoin/comments/38sucy/funds_stuck_in_copay_2of3_wallet_need_help/crxq2f1

NOTE Using custom code it was proven possible to independently sweep a Copay 1of1 P2SH wallet using the backup blob

• Source code is public and kept up to date under version control system

PASS https://github.com/bitpay/copay

• If user has no access to some of the private keys in a multi-signature wallet:

N/A While this is a multsig wallet, the service does not hold any of the keys

• Provides 2FA authentication feature
• Reminds the user to enable 2FA by email or in the main UI of the wallet
• User session is not persistent, or requires authentication for spending
• Gives control to the user over moving their funds out of the multi-signature wallet
• For hardware wallets:

N/A

• Uses the push model (computer malware cannot sign a transaction without user input)
• Protects the seed against unsigned firmware upgrades
• Supports importing custom seeds
• Provides source code and/or detailed specification for blackbox testing if using a closed-source Secure Element

Optional criterias (some could become requirements):

• Received independent security audit(s)

NOTE No known independent audits

• Avoid address reuse by using a new change address for each transaction

PASS A new change address is used for each transaction, confirmed using custom code to verify each address was used only once

• Avoid address reuse by displaying a new receiving address for each transaction in the wallet UI

PASS A new receive address is displayed for each transaction

• Does not show "received from" Bitcoin addresses in the UI

PASS Does not show received from addresses

• Uses deterministic ECDSA nonces (RFC 6979)

PASS Uses deterministic nonces

NOTE Currently not compatible with RFC 6979. BitPay is correcting this bitpay/bitcore#1269

NOTE Uses LowS signature values per BIP62

• Provides a bug reporting policy on the website

FAIL Only links on website are to github repository
NOTE Github readme has bug reporting guidelines, but no suggestion on where to report it
NOTE No bug reporting instructions in the app or in iOS app store
NOTE support@bitpay.com email address is listed in Google Play

NOTE While the address is not provided, support@bitpay.com is backed by a professional support organization, with prompt responses and excellent followthrough

• If user has no access over its private keys:

N/A

• Full reserve audit(s)
• Insurrance(s) against failures on their side
• Reminds the user to enable 2FA in the main UI of the wallet
• If user has exclusive access over its private keys:
  • Supports HD wallets (BIP32)

PASS Uses BIP32

NOTE Uses BIP45 style paths (e.g. m/45'/2147483647/c/i for 1of1 wallets)

NOTE Note that single signature wallets use P2SH, not P2PKH. This is less efficient.

• Provides users with step to print or write their wallet seed on setup

PASS If a backup has not been done, a full screen reminder is presented on the Receive tab

• Uses a strong KDF and key stretching for wallet storage and backups

PASS Uses PBKDF2 with 10000 iterations and 128 bit AES

• On desktop platform:
  • Encrypt the wallet by default

FAIL Wallets are not encrypted by default, but:

NOTE The wallet’s private key (only) can be encrypted from the settings page

• For hardware wallets:
  • Prevents downgrading the firmware

N/A

[wbnns]

@crwatkins I think the issue w/ Qualys is that it's trying to do the scan based off of the common name on the certificate, which is Bitcore.io - https://bitcore.io/ times out when accessed via HTTPS.

Edit: Also just wanted to add, thank you for doing a thorough and comprehensive review. Also, awesome job to @bitjson dialing all of this in. @crwatkins - if they get the SSL issue fixed, so Qualys runs (perhaps by enabling HTTPS on Bitcore.io), is that sufficient then to get your recommendation for listing?

[crwatkins]

Will, that may be; Qualys does a lot of different types of connections to test the site. However, I get similar connection problems using curl (see above) and even openssl s_client:

$ openssl version
OpenSSL 0.9.8zd 8 Jan 2015
$ openssl s_client -connect copay.io:443
CONNECTED(00000003)
74405:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:/SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/ssl/s23_clnt.c:593:

I haven't done any recent debugging but when I very quickly wiresharked it a couple weeks ago the SSL alert occurred immediately after the ClientHello (i.e. no ServerHello received). I haven't looked beyond that.

[matiu]

Thanks a lot @crwatkins for the in-depth review and all the hard work!

We will be working on SSL described issue and adding HSTS at the landing page (copay.io) as soon as we can, and will update this thread when is ready.

[crwatkins]

@matiu, I believe the issue with the broken SSL connection is related to SNI. If I send a SNI with copay.io, things work as expected (completes a full SSL handshake), e.g.

% openssl s_client -connect copay.io:443 -servername copay.io

The issue may relate to your server handling of SNI.

[matiu]

Thanks @crwatkins

Following this guide https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html

we had remake our webserver configuration files, so now https://www.ssllabs.com/ssltest/analyze.html?d=copay.io shows "A+" as general rate. We have also added HSTS.

Thanks a lot for the suggestions.

Could you please review it now?

[harding]

@crwatkins great review! I wanted to point out a couple interesting points for anyone who missed them:

NOTE Using custom code it was proven possible to independently sweep a Copay 1of1 P2SH wallet using the backup blob
[...]
NOTE Currently not compatible with RFC 6979. BitPay is correcting this bitpay/bitcore#1269

.... that's some really detailed reviewing. For the RFC6979 part, Craig took the time to independently sign a copy of a Copay-made transaction with a separate RFC6979-compliant Bitcoin implementation. He noticed it didn't match, contacted BitPay, and helped them discover the issue described in bitpay/bitcore#1269 . I find this very impressive---thanks, @crwatkins!.

@matiu I see a "B" (not "A+") as the general rating on https://www.ssllabs.com/ssltest/analyze.html?d=copay.io , but that's a passing score and it now says HSTS is set to 730 days. Based on this and @crwatkins's review, I support adding Copay to the site.

In the absence of critical feedback, this PR will be merged Tuesday.

[matiu]

thanks @harding. I do agree that @crwatkins did a terrific, in-depth review.

I see "A+" on https://www.ssllabs.com/ssltest/analyze.html?d=copay.io&latest
(https://www.evernote.com/shard/s49/sh/35e3f4ab-2b99-4d1c-aa85-78078bee8f7a/9c0816892cb478457fda50ae01c0d7c4)

maybe try "clear cache"?

[harding]

A+ now confirmed, I think appending &latest to URL the did the trick. That's great, thanks @matiu!

[harding]

@crwatkins just sent me an email reminding me that he had multiple objections to the scoring text changes as described in this comment. @bitjson can you look into those please?

[wbnns]

Nice work @bitjson @matiu and @crwatkins.

[crwatkins]

@harding Thanks for noting my objections while I was offline.

As for the review:

• SSL certificate passes Qualys SSL Labs SSL test

PASS copay.io A+ rating

• Website serving executable code or requiring authentication uses HSTS with a max-age of at least 180 days

PASS max-age is 730 days

Contingent upon resolution of the scoring in the PR request, I am glad to recommend Copay for listing.

[saivann]

Agreed with @crwatkins , huge thanks for this amazing review work!

[harding]

Note, in addition to coming to agreement on the scoring text, this now also needs to be rebased to prevent a conflict in _translations/en.yml (sorry).

[bitjson]

Thank you @crwatkins for your very thorough review. I just made changes based on your comments.

---

web category is a selection criteria that users employ to find a wallet which they do not need to "install" on a computer (which they may not have control over).

👍

Makes sense. I've removed the web section from Copay's platforms for now.

---

I support making some changes in this area eventually, but I would like to hold off adding more classifications

I also agree about the value of reducing "classification creep”. If users can't understand the difference between criteria, the value of this list is diminished.

Since this page is often used (even by very technical bitcoin users) to quickly understand the security and privacy implications of various wallets, I also think accuracy is a top priority.

There are already a number of bitcoin companies using Copay as a corporate wallet – in fact, this is the primary demographic Copay is designed to accommodate. The self-hosting feature is of production-critical importance to them. It would be unacceptable for BitPay or another entity to have the ability to DOS (or even observe the usage of) their wallets.

I’m not an expert, but I believe this architecture is arguably more secure and privacy-protecting than an SPV wallet. A self-hosted BWS node is fully validating, and can even insulate the Copay wallet using whatever privacy-enhancing measures the organization chooses to implement. To promote secure usage and avoid misconceptions, I think it's valuable to add this architecture to the possible classifications.

As an added benefit, these additional classifications may motivate other wallets providers to open source their servers and provide the option to self-host a remote node.

Validation

We currently have the following choices:

• Full (full node)
• Simplified (SPV)
• Decentralized (GreenAddress' randomized list method)
• Centralized (trust-based)

Obviously, it could give a false sense of security to mark Copay with "Full validation”, though that is the level our business users are getting. Similarly, I’m worried that “Centralized validation” will promote serious misconceptions. I think the "Remote validation” option in this PR completes this list and provides valuable additional information.

If we wanted to try to simplify the list further, I'd propose we widen the meaning of "Decentralized validation" to fit Copay's architecture too, rather than limiting it to just the randomized node selection implementation in GreenAddress. I think more information is preferable to oversimplification in this case though, as validation is a security-defining concept in wallet architecture. 5 classifications seem reasonable to me for this particular area.

Privacy

For privacy we currently have:

• Avoids disclosing information (full node)
• Discloses limited information to peers (SPV)
• Discloses information to a third party

Here again, the proper category for self-hosting users would be "avoids disclosing information" (depending on configuration, this can provide better privacy than an SPV client). For non-hosting users, some information is disclosed to the remote node. I think the "Discloses information to a remote node" classification in this PR completes the spectrum of possible privacy configurations for wallets, and is likely to be used by other wallets currently in development.

---

Again thanks for the detailed review. I’d appreciate your thoughts on this, and if possible, I’d really like to win you over.

I’d prefer to finalize Copay’s scoring in this PR rather than waiting for a rewrite of this page. As I see it, I can go the extra mile to clarify details here, or I can spend much of my time in the next few months answering emails and calming the fears of potential business users. 😄

[crwatkins]

This PR request is to add the Copay wallet. If we want to make changes to the scoring criteria that will affect other wallets I believe we should have a separate PR with a subject that publicly indicates our intent. (My guess without checking is that the majority of the wallets that are currently scored to use a central server will tell you that you can set up your own if you want.) I believe that PR should include the changes to the scoring for wallets that are affected.

[wbnns]

I concur w/ @crwatkins that changes to scoring criteria should be a separate PR. Also @bitjson, FWIW, I agree with you that the scoring criteria could be improved. Thanks for putting the thought and effort into elaborating on your perspective.

[saivann]

@crwatkins @Coderwill Agreed, makes sense!

[bitjson]

@crwatkins @Coderwill @saivann thank you for the input – I separated the classifications from this PR and submitted them in #927. I'll continue this thread there.

Are there any further changes that need to be made to this pull request? Thank you all for reviewing.

[crwatkins]

@bitjson, thanks for helping us move forward with the wallets classification.

On this pull request, I would suggest that checkgoodcontrolfull applies to Copay. Our control category has historically applied to whether the third party wallet/server vendor has had access or freeze control over your funds. I believe your new score of checkpasscontrolshared describes a feature of multi-sig wallets in which you can choose to share control of your wallet with your own delegates (to be pedantic, I'm not considering your multi-sig delegates a "third party"). We try to keep away from describing wallet features in scores as much as possible.

With that change, I would recommend this PR for merge.

@bitjson, thanks for all your extra work here.

[bitjson]

@crwatkins good idea, just made the change. Thanks for keeping the wallet section so well-maintained!

[crwatkins]

LGTM for merge.

[saivann]

LGTM up to commit cbcde1b . Thanks!

[harding]

In the absence of critical feedback, this will be merged on Friday. Thanks!