From b541875da5248905e7af52fc72c3d76d76e05dc6 Mon Sep 17 00:00:00 2001 From: Saivann Date: Fri, 5 Dec 2014 10:17:21 -0500 Subject: [PATCH 01/11] Set general requirements and process for including wallets --- README.md | 56 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+) diff --git a/README.md b/README.md index ba0c878d..04800f9b 100644 --- a/README.md +++ b/README.md @@ -254,6 +254,62 @@ More information will follow. ## Wallets +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. + +Basic requirements: + +- Sufficient users and/or developers feedback can be found without particularly concerning issues, or independent security audit(s) is available +- No indication that users have been harmed or risked being harmed by any issue in relation to the wallet +- Wallet was publicly announced and released since at least 3 months +- No concerning bug is found when testing the wallet +- Website supports HTTPS and 301 redirects HTTP requests +- SSL certificate passes [Qualys SSL Labs SSL test](https://www.ssllabs.com/ssltest/) +- The identity of CEOs and/or developers is public +- For custodial wallets: + - 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 + - Refuses weak passwords (short passwords and/or common passwords) + - Provides account recovery feature +- For non-custodial wallets: + - Allows backup of the wallet + - Restoring wallet from backup is working + - Source code is public and kept up to date under version control system +- For multi-signature wallets: + - 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 + - Refuses weak passwords (short passwords and/or common passwords) + - Gives control to the user over moving their funds out of the multi-signature wallet +- For hardware wallets: + - Uses the push model (computer malware cannot sign a transaction without user input) + - Refuses 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) +- Rotates change addresses +- Rotates receiving addresses in the wallet UI +- Does not show "received from" Bitcoin addresses in the UI +- Uses deterministic ECDSA nonces (RFC 6979) +- For custodial wallets: + - Enables HSTS + - Full reserve audit(s) + - Insurrance(s) against failures on their side + - Reminds the user to enable 2FA in the main UI of the wallet +- For non-custodial wallets: + - Supports HD wallets (BIP32) + - Provides users with step to print or write their wallet seed on setup + - Uses a strong KDF and key stretching for wallet storage and backups + - On desktop platform: + - Encrypt the wallet by default +- For hardware wallets: + - Prevents downgrading the firmware + +### Adding a wallet + Wallets can be added in `_templates/choose-your-wallet.html`. Entries are ordered by levels and new wallets must be added after the last wallet on the same level. * Level 1 - Full nodes From c042987334e6706df2990a1a50054afe58460a65 Mon Sep 17 00:00:00 2001 From: Saivann Date: Fri, 5 Dec 2014 22:02:12 -0500 Subject: [PATCH 02/11] Mention that wallets guidelines can be adapted (thanks @harding) --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index 04800f9b..a1f6f49a 100644 --- a/README.md +++ b/README.md @@ -256,6 +256,8 @@ More information will follow. 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. +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 particularly concerning issues, or independent security audit(s) is available From 1037acfe185a4789997199f00a02c7c4e751be2c Mon Sep 17 00:00:00 2001 From: Saivann Date: Sat, 6 Dec 2014 13:52:04 -0500 Subject: [PATCH 03/11] Replace confusing mentions of "custodial" wallets --- README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index a1f6f49a..f7370e01 100644 --- a/README.md +++ b/README.md @@ -267,17 +267,17 @@ Basic requirements: - Website supports HTTPS and 301 redirects HTTP requests - SSL certificate passes [Qualys SSL Labs SSL test](https://www.ssllabs.com/ssltest/) - The identity of CEOs and/or developers is public -- For custodial wallets: +- If user has no access over its 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 - Refuses weak passwords (short passwords and/or common passwords) - Provides account recovery feature -- For non-custodial wallets: +- If user has exclusive access over its private keys: - Allows backup of the wallet - Restoring wallet from backup is working - Source code is public and kept up to date under version control system -- For multi-signature wallets: +- If user has no access to some of the private keys in a multi-signature wallet: - 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 @@ -296,12 +296,12 @@ Optional criterias (some could become requirements): - Rotates receiving addresses in the wallet UI - Does not show "received from" Bitcoin addresses in the UI - Uses deterministic ECDSA nonces (RFC 6979) -- For custodial wallets: +- If user has no access over its private keys: - Enables HSTS - Full reserve audit(s) - Insurrance(s) against failures on their side - Reminds the user to enable 2FA in the main UI of the wallet -- For non-custodial wallets: +- If user has exclusive access over its private keys: - Supports HD wallets (BIP32) - Provides users with step to print or write their wallet seed on setup - Uses a strong KDF and key stretching for wallet storage and backups From ed063e3eda0168ab72cfba7f263940e8fc1f7b0b Mon Sep 17 00:00:00 2001 From: Saivann Date: Sat, 6 Dec 2014 14:01:18 -0500 Subject: [PATCH 04/11] Avoid forcing signed firmware updates for hardware wallets (thanks @luke-jr) --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index f7370e01..7dde7454 100644 --- a/README.md +++ b/README.md @@ -285,7 +285,7 @@ Basic requirements: - Gives control to the user over moving their funds out of the multi-signature wallet - For hardware wallets: - Uses the push model (computer malware cannot sign a transaction without user input) - - Refuses unsigned firmware upgrades + - Protect 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 From ffd2bcaaedf1436a117ae47d9f44f75d5c1a6031 Mon Sep 17 00:00:00 2001 From: Saivann Date: Sat, 6 Dec 2014 14:01:51 -0500 Subject: [PATCH 05/11] Clarify that rotating addresses is used to avoid address reuse (thanks @luke-jr) --- README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 7dde7454..c6e2731a 100644 --- a/README.md +++ b/README.md @@ -285,15 +285,15 @@ Basic requirements: - Gives control to the user over moving their funds out of the multi-signature wallet - For hardware wallets: - Uses the push model (computer malware cannot sign a transaction without user input) - - Protect the seed against unsigned firmware upgrades + - 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) -- Rotates change addresses -- Rotates receiving addresses in the wallet UI +- Avoid address reuse by rotating change addresses +- Avoid address reuse by rotating receiving addresses in the wallet UI - Does not show "received from" Bitcoin addresses in the UI - Uses deterministic ECDSA nonces (RFC 6979) - If user has no access over its private keys: @@ -355,9 +355,9 @@ To get a passing score, the wallet must run from an environment that provides ap **Privacy**: Does the wallet protect users' privacy? -To get a good score, the wallet must rotate addresses, avoid disclosing information to peers or central servers and be compatible with Tor. +To get a good score, the wallet must avoid address reuse by rotating change addresses, avoid disclosing information to peers or central servers and be compatible with Tor. -To get a passing score, the wallet must rotate addresses. +To get a passing score, the wallet must avoid address reuse by rotating change addresses. ## Advanced Usage From 8eed2466f1f88b5bda125c1dad6932c0680f5223 Mon Sep 17 00:00:00 2001 From: Saivann Date: Sat, 6 Dec 2014 14:25:56 -0500 Subject: [PATCH 06/11] Drop confusing "rotate address" mentions --- README.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index c6e2731a..2549e321 100644 --- a/README.md +++ b/README.md @@ -292,8 +292,8 @@ Basic requirements: Optional criterias (some could become requirements): - Received independent security audit(s) -- Avoid address reuse by rotating change addresses -- Avoid address reuse by rotating receiving addresses in the wallet UI +- Avoid address reuse by using a new change address for each transaction +- Avoid address reuse by displaying a new receiving address for each transaction in the wallet UI - Does not show "received from" Bitcoin addresses in the UI - Uses deterministic ECDSA nonces (RFC 6979) - If user has no access over its private keys: @@ -355,9 +355,10 @@ To get a passing score, the wallet must run from an environment that provides ap **Privacy**: Does the wallet protect users' privacy? -To get a good score, the wallet must avoid address reuse by rotating change addresses, avoid disclosing information to peers or central servers and be compatible with Tor. +To get a good score, the wallet must avoid address reuse by using a new change address for each transaction, avoid disclosing information to peers or central servers and be compatible with Tor. + +To get a passing score, the wallet must avoid address reuse by using a new change address for each transaction. -To get a passing score, the wallet must avoid address reuse by rotating change addresses. ## Advanced Usage From 55aaa165502830fa777e902b34eca76006000c7a Mon Sep 17 00:00:00 2001 From: Saivann Date: Wed, 10 Dec 2014 00:28:41 -0500 Subject: [PATCH 07/11] Update wallet inclusion requirements with good coding practices --- README.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 2549e321..7bc3754e 100644 --- a/README.md +++ b/README.md @@ -260,8 +260,11 @@ Innovative wallets are exciting and encouraged, so if your wallet has a good rea Basic requirements: -- Sufficient users and/or developers feedback can be found without particularly concerning issues, or independent security audit(s) is available -- No indication that users have been harmed or risked being harmed by any issue in relation to the wallet +- Sufficient users and/or developers feedback can be found without concerning issues, or independent security audit(s) is available +- No indication that users have been harmed considerably by any issue in relation to the wallet +- 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 +- No indication that the wallet uses unstable or unsecure libraries +- No indication that changes to the code are not properly tested - Wallet was publicly announced and released since at least 3 months - No concerning bug is found when testing the wallet - Website supports HTTPS and 301 redirects HTTP requests From bc778b8f64c9a42f2216362bb49a50d941501db7 Mon Sep 17 00:00:00 2001 From: Saivann Date: Wed, 10 Dec 2014 00:34:45 -0500 Subject: [PATCH 08/11] Apply "strong passwords" requirement to hybrid wallets --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 7bc3754e..5274d4ff 100644 --- a/README.md +++ b/README.md @@ -270,11 +270,12 @@ Basic requirements: - Website supports HTTPS and 301 redirects HTTP requests - SSL certificate passes [Qualys SSL Labs SSL test](https://www.ssllabs.com/ssltest/) - The identity of CEOs and/or developers is public +- If private keys are stored online: + - Refuses weak passwords (short passwords and/or common passwords) - If user has no access over its 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 - - Refuses weak passwords (short passwords and/or common passwords) - Provides account recovery feature - If user has exclusive access over its private keys: - Allows backup of the wallet @@ -284,7 +285,6 @@ Basic requirements: - 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 - - Refuses weak passwords (short passwords and/or common passwords) - Gives control to the user over moving their funds out of the multi-signature wallet - For hardware wallets: - Uses the push model (computer malware cannot sign a transaction without user input) From b81cd7dd062018226bf97ac87420eba909f89741 Mon Sep 17 00:00:00 2001 From: Saivann Date: Thu, 11 Dec 2014 13:11:36 -0500 Subject: [PATCH 09/11] Allow for PIN login with aggressive lock-out (thanks gurnec) --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 5274d4ff..16d2219c 100644 --- a/README.md +++ b/README.md @@ -270,8 +270,8 @@ Basic requirements: - Website supports HTTPS and 301 redirects HTTP requests - SSL certificate passes [Qualys SSL Labs SSL test](https://www.ssllabs.com/ssltest/) - The identity of CEOs and/or developers is public -- If private keys are stored online: - - Refuses weak passwords (short passwords and/or common passwords) +- 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. - If user has no access over its private keys: - Provides 2FA authentication feature - Reminds the user to enable 2FA by email or in the main UI of the wallet From 82453bbcc2d6b5f0a52391b0d854fb8beddfcdbb Mon Sep 17 00:00:00 2001 From: Saivann Date: Thu, 11 Dec 2014 23:27:25 -0500 Subject: [PATCH 10/11] Explicitely mention that the requirements are meant to change and strengthen over time (thanks gmaxwell) --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 16d2219c..1b3d0063 100644 --- a/README.md +++ b/README.md @@ -256,7 +256,7 @@ More information will follow. 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. -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. +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: From 5b475ee2af5f93c91d786e562973ba70558ac4fd Mon Sep 17 00:00:00 2001 From: Saivann Date: Thu, 11 Dec 2014 23:29:57 -0500 Subject: [PATCH 11/11] Add a bug reporting policy as an optional criteria (thanks gmaxwell) --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 1b3d0063..9fdc7f57 100644 --- a/README.md +++ b/README.md @@ -299,6 +299,7 @@ Optional criterias (some could become requirements): - Avoid address reuse by displaying a new receiving address for each transaction in the wallet UI - Does not show "received from" Bitcoin addresses in the UI - Uses deterministic ECDSA nonces (RFC 6979) +- Provides a bug reporting policy on the website - If user has no access over its private keys: - Enables HSTS - Full reserve audit(s)