walletencryption password strength (only QT) #5278

1. 
   jonasschnelli commented at 8:05 am on November 14, 2014: contributor

   I’m could not find any github-discussion about password strength of the wallet encryption passphrase. By default all types of weak passwords are allowed (even without warning) to encrypt your wallet.

   Would it not be possible to add a password strength police to the RPC command as well to the GUI form?

   Suggestion: RPC: the encryptwallet RPC command should reject a weak passphrase unless a -force arg is given (or we could even drop the -force arg and/or only allow weak passphrase if a startup-arg -allowweakpassphrase was set).

   GUI: while entering a encryption passphrase there could be a green/orange/red icon to show the password strength. Using a “orange” or “red” password is forbidden unless he clicks through warnings or had -allowweakpassphrase enabled.

2. 
   Diapolo commented at 8:58 am on November 14, 2014: none

   I’m not sure we should add -allowweakpassphrase, but of course warn if certain parameters of a passphrase are considered insecure. What parameters must be met should be discussed, right. Also you need to consider, what about already encrypted wallets, should/will there be a warning, too?
3. 
   jonasschnelli commented at 9:31 am on November 14, 2014: contributor

   @Diapolo once the wallet is encrypted, we could only check the passphrase strength when he enters the password. And this is IMO uncommon. I think we should focus on new wallets. For already encrypted wallets it’s IMO to late to check the password strength.

   The -allowweakpassphrase is bad practice. Right. We might go for the -force arg for encryptwallet RPC command. I think people would scream up if there is not such weak-password-allowing possibility.

4. 
   laanwj commented at 10:34 am on November 14, 2014: member

   Not sure about this. You can add arbitrary checks and policies, but it’s never guaranteed that passwords that pass them are actually any safer. So passing the test gives people a false sense of security.

   So you can say a password <4 characters is unsafe, by definition, but a even a 24 character password may be vulnerable to dictionary attack (w/ replacement/addition of ‘special characters’).

   Anyhow if you do this, do it only for the GUI. For the RPC it makes no sense. RPC is advanced usage (and aimed at usage by other programs), no need to hand-hold users there.

5. laanwj added the label GUI on Nov 14, 2014
6. 
   jonasschnelli commented at 12:55 pm on November 14, 2014: contributor

   Agreed: on RPC level we don’t need to hold-hands. GUI: personally, i hate password strength checker. But even if bitcoin-qt is a devs-, experts-wallet, i see many unexperienced users using it.

   Every password strength checking has his weakness. I think we should just follow the common rules (http://en.wikipedia.org/wiki/Password_strength#Guidelines_for_strong_passwords) to end up warning in about 95% of all weak passwords (whatever weak means :) ).

   Still users should be allowed to use super-weak passwords like “1” or “test”. But they have to go through at min. one warning.

7. jonasschnelli renamed this:
   walletencryption password strength (bitcoind and QT)
   walletencryption password strength (only QT)
   on Jan 9, 2015
8. laanwj added the label Feature on Feb 16, 2016
9. 
   MarcoFalke commented at 9:55 am on June 1, 2016: member

   Currently, there are already suggestions on what a strong password looks like:

   

   I think before forcing strong passwords, we should make sure there is a convenient way to have a backup/emergency recovery passphrase. E.g printed QR-Code + small nonce written down by hand on the QR-Code. (This was suggested in in Zürich)

10. 
    MarcoFalke commented at 0:13 am on April 27, 2020: member

    Is this still relevant after #17950 ?
11. MarcoFalke closed this on Apr 27, 2020

    ---

12. DrahtBot locked this on Feb 15, 2022

Contributors
jonasschnelli Diapolo laanwj MarcoFalke

Labels
Feature GUI