Able to create a wallet with a weak passphrase, then told to delete persistent storage by BAILS

[extrapockets]

I had a weak password for my Tail persistent storage, yet BAILS allowed me to make multiple wallets using that weak password as a passphrase (Keepassxc says it's < 40 bits entropy). Recently, upon restoring a wallet, my passphrase (identical to my weak Tails pw) failed the entropy check in Bails/bin/persistent-setup:

print("")' 2>/dev/null)"
        if [ -z "$existing_passphrase" ]; then
            zenity --error --title="Error" --text="Existing Persistent Storage passphrase is required. Please provide the passphrase." $ICON
        else
            # Estimate passphrase entropy to see if we can proceed
            entropy=$(keepassxc-cli estimate "${existing_passphrase// /}" | cut -f2 | tr -C -d '[:digit:]')
            if ((entropy >= 65000)); then
                break
            elif ((entropy > 50000)); then
                zenity --question --icon-name=dialog-warning --title='Warning: Weak Passphrase Detected' \
                  --text="Your passphrase is too weak..." \
                  --width=600 $ICON --ok-label='Continue' --default-cancel --cancel-label='Restart Now' && break || exit 1
            else
                zenity --warning --title='WARNING: Weak Passphrase Detected' \
                  --text="Your passphrase is too weak...." \
                  --width=600 $ICON --ok-label='Restart Now'
                exit 1

I don't know why I was allowed to create the wallet with the weak passphrase in the first place. One wallet was created three weeks ago, and another with the same weak passphrase was created two days ago. Now I've been funneled to the warning that I MUST delete my persistent storage and start over. I am planning to clone BAILS to avoid another long sync process, but this would be a discouraging situation for a user to find themselves in.

[BenWestgate]

The check for Persistent Storage passphrase strength uses zxcvbn and indeed <50 bits is the cut off I tell users who already have a persistent storage to create a new one at.

The check for creating a seed backup passphrase or wallet spending passphrase is just that it is 12 characters, although I may eventually add an entropy requirement as well.

Would you like bails-wallet to require 50-bits of entropy on wallet passphrases or seed backup passphrases?

The only way you got into this situation is because you did not use a recommended passphrase when you set up Persistent Storage.

When you make a backup, it lets you set a passphrase for the new clone, so you're absolutely able to recover from this issue.

Can you tell me how you got shown this message?

print("")' 2>/dev/null)"
        if [ -z "$existing_passphrase" ]; then
            zenity --error --title="Error" --text="Existing Persistent Storage passphrase is required. Please provide the passphrase." $ICON
        else
            # Estimate passphrase entropy to see if we can proceed
            entropy=$(keepassxc-cli estimate "${existing_passphrase// /}" | cut -f2 | tr -C -d '[:digit:]')
            if ((entropy >= 65000)); then
                break
            elif ((entropy > 50000)); then
                zenity --question --icon-name=dialog-warning --title='Warning: Weak Passphrase Detected' \
                  --text="Your passphrase is too weak..." \
                  --width=600 $ICON --ok-label='Continue' --default-cancel --cancel-label='Restart Now' && break || exit 1
            else
                zenity --warning --title='WARNING: Weak Passphrase Detected' \
                  --text="Your passphrase is too weak...." \
                  --width=600 $ICON --ok-label='Restart Now'
                exit 1

I use a passphrase of 'a' all the time in testing and have never seen it.

It's supposed to only show up when you have an existing Persistent Storage and not BAILS and try to install Bails to it. It won't let you if your Persistent Storage passphrase is weak.

[BenWestgate]

This is the guidance from Bitcoin Core on passphrases for instance.

It works out to be about 50 bits for 10 random characters if lowercase and 8 words is about 40 characters which when chosen non-randomly is about 1.2 bits of entropy per character or 48.

Bitcoin core has considerably weaker keystretching than luks2 full disk encryption that protects your Persistent Storage.

A passphrase that's weak for luks2 is trivial to crack on Bitcoin Core if your wallet file was stolen.

[extrapockets]

Can you tell me how you got shown this message?

I grabbed that code (and shortened the long warning strings with '...') from [https://github.com/BenWestgate/Bails/blob/master/bin/persistent-setup](the repo) when I was searching for the way entropy is calculated. I did not get that particular text while running BAILS.

I used BAILS to initially create the persistent storage, as per the README, but got the warning "you MUST restart, delete this Persistent Storage and use a recommended passphrase" later on after updating BAILS and restoring a wallet.

[BenWestgate]

That's the main reason I'm letting people use 5 or 6 words from the Persistent Storage suggestion. 4 would probably be enough for people not storing millions. But it might be borderline for wallet encryption and the easier user experience is reusing passphrases for these different encryption layers. (although it's not required, you can restore from seed were you to forget a wallet encryption passphrase)

[extrapockets]

Bitcoin core has considerably weaker keystretching than luks2 full disk encryption that protects your Persistent Storage.

A passphrase that's weak for luks2 is trivial to crack on Bitcoin Core if your wallet file was stolen.

That's good to know.

the easier user experience is reusing passphrases for these different encryption layers.

Completely agree here. I like only having to remember one long passphrase.

[BenWestgate]

Can you tell me how you got shown this message?

I grabbed that code (and shortened the long warning strings with '...') from [https://github.com/BenWestgate/Bails/blob/master/bin/persistent-setup](the repo) when I was searching for the way entropy is calculated. I did not get that particular text while running BAILS.

I used BAILS to initially create the persistent storage, as per the README, but got the warning "you MUST restart, delete this Persistent Storage and use a recommended passphrase" later on after updating BAILS and restoring a wallet.

The snippet you sent should only run when Bails is not installed and the user tries to install it. I will check why this happened. It could be that you capitalized or didn't capitalize "bails"/"Bails" when you reinstalled. I should rename the folder to be in consistent lower-case so the check always works.

In your case, you chose a weak passphrase for persistent storage by not following the on screen instructions on your initial install.

Do you think the initial install instructions should be more clear about choosing a strong passphrase from the suggestion in Persistent Storage?

For example the strength meter is far too optimistic and dumb, Tails is considering removing it, but I'd rather they just updated the passphrase entropy calculations and thresholds. You may have stopped when your passphrase was called "Strong" and found later it was not.

If you want to get past that error message just produce an actual strong passphrase and it will let you continue. Then you can use tails-cloner or tails-installer to create a backup Bails with a better passphrase.

As for your codex32 seeds where you may have reused this passphrase as a "seed backup passphrase", I don't currently have a way to change the passphrase (it is possible and a planned option, it requires replacing every share however.) So you'll have to create a new backup using a better passphrase if you're concerned about an attacker brute forcing the "seed backup passphrase", I wouldn't use a passphrase under 40-bits there unless you only need casual privacy against non-technical snoops. It's likely it can be brute forced for a few thousand or less.

[BenWestgate]

I can't reproduce your issue following your steps.
Can you type:
[ -f $HOME/.local/share/*/b ]; echo $? in the terminal of the machine that give you the message while your Persistent Storage is unlocked?

I get 0 the code should not run unless this file is missing, which it should not be unless you messed around in the dotfiles and deleted it.

[extrapockets]

Would you like bails-wallet to require 50-bits of entropy on wallet passphrases or seed backup passphrases?

I wouldn't use a passphrase under 40-bits there unless you only need casual privacy against non-technical snoops.

I agree, I only used the weak passphrase on persistent storage to set up Tails and bails for testing with a minimal amount of sats. The best flow is only needing one passphrase for both tails and the wallet backup.

In your case, you chose a weak passphrase for persistent storage by not following the on screen instructions on your initial install.

Do you think the initial install instructions should be more clear about choosing a strong passphrase from the suggestion in Persistent Storage?

Yes, I think the entropy requirement should be rather stern to encourage users to be able to only remember one passphrase. I just ignored the initial install's suggestion like you said - I wanted to get moving and I had already written down the weak (merely 'strong') Tails password that I wanted to use.

[BenWestgate]

The best flow is only needing one passphrase for both tails and the wallet backup.

I don't have any plans to change that. So you're ACK, the passphrase requirements for Wallet Encryption / Seed backup passphrase should be the same as what is recommended (but not enforced) for Persistent Storage?

Yes, I think the entropy requirement should be rather stern to encourage users to be able to only remember one passphrase. I just ignored the initial install's suggestion like you said - I wanted to get moving and I had already written down the weak (merely 'strong') Tails password that I wanted to use.

Thing is unless I merge changes into Tails (I have before). I don't know what passphrase users gave to Persistent Storage, that's why I have to ask for it right afterwards to start the spaced-repetition training. If they gave a weak one, it's a big mess to say OK, now we can't continue unless you change the passphrase.

And worse, changing the passphrase on flash memory doesn't erase the old passphrase's ability to unlock your data, so it's not increasing security against an adversary with forensic tools (tends to be the same one who would brute force a passphrase in the first place).

So that's why the message on re-install says to delete the persistent storage and create a new one, as that's the only way to protect new data.

[extrapockets]

I get 2

[extrapockets]

Thanks for the prompt responses. I'll be back at my computer later to continue with this issue.

[BenWestgate]

To investigate further, can you verify the path $HOME/.local/share/bails/b exists?

after you get the error?

Also I may have added code that handles this case where persistence already exists and someone tries to install bails after you installed bails 3 weeks ago. I don't remember. But on my machine the file exists and I get 1.

Also try

dotfiles/.local/share/bails/b and tell me if that file exists if the first one does not.

[extrapockets]

So you're ACK, the passphrase requirements for Wallet Encryption / Seed backup passphrase should be the same as what is recommended (but not enforced) for Persistent Storage?

ACK. If users can use their favorite <50bit password and get away with it, many unfortunately will (as I did during the initial install).

I don't know what passphrase users gave to Persistent Storage, that's why I have to ask for it right afterwards to start the spaced-repetition training.

I had closed bails immediately after cloning it via terminal to avoid the spaced repetition warnings (they had previously froze my Computer during a Bitcoin Core blockchain sync while I was away from the computer for a few days, as noted in this comment in this issue. So makes sense that I ended up using a password that did not have enough entropy for bails.

And worse, changing the passphrase on flash memory doesn't erase the old passphrase's ability to unlock your data, so it's not increasing security against an adversary with forensic tools (tends to be the same one who would brute force a passphrase in the first place).

Wow, good to know. I can see why the persistent storage must be deleted (thankfully the clone option should work for this situation).

To investigate further, can you verify the path $HOME/.local/share/bails/b exists?

Yes, it exists. But so does $HOME/.local/share/Bails/b (Title case Bails).

dotfiles/.local/share/bails/b and tell me if that file exists if the first one does not

As I mention just above, I did have the ...bails/b & .../Bails/b paths. Regarding dotfiles, I don't see anything in my dotfiles folder. I can't access /live/persistence/TailsData_unlocked with 'sudo', as I followed Tail's recommendation to not set up an Administrator password.

[BenWestgate]

Ah this must be why. You spelled bails differently the second time you git cloned it so there are two installations on your Tails. That command * is a wild card so it gives you “2” because it found more than 1 file for that path with a wildcard. Again I’ll make bails rename the folder to lowercase before saving it to the persistent storage and this warning you get wouldn’t happen. As for setting a minimum strength for the seed backup paraphrase and wallet encryption passphrase, I am going to wait because I’m rewriting bails-wallet in Python and will need to see what cross platform tools I have available. (KeePassXC may not be everyone’s system and it might not be worth requiring it to be, for instance. Must weigh a new dependency having access to the passphrase vs the gains of better strength estimation. If zxcvbn is not readily available or popular for Python, likely I will make the minimum length 20 characters and use what is popular and available for passphrase strength estimation even if it’s not as good as zxcvbn

…

On Mon, Sep 11, 2023 at 15:39, extrapockets ***@***.***(mailto:On Mon, Sep 11, 2023 at 15:39, extrapockets <<a href=)> wrote: > So you're ACK, the passphrase requirements for Wallet Encryption / Seed backup passphrase should be the same as what is recommended (but not enforced) for Persistent Storage? ACK. If users can use their favorite <50bit password and get away with it, many unfortunately will (as I did during the initial install). > I don't know what passphrase users gave to Persistent Storage, that's why I have to ask for it right afterwards to start the spaced-repetition training. I had closed bails immediately after cloning it via terminal to avoid the spaced repetition warnings (they had previously froze my Computer during a Bitcoin Core blockchain sync while I was away from the computer for a few days, as noted in [this comment](#50 (comment)) in [this issue](#50). So makes sense that I ended up using a password that did not have enough entropy for bails. > And worse, changing the passphrase on flash memory doesn't erase the old passphrase's ability to unlock your data, so it's not increasing security against an adversary with forensic tools (tends to be the same one who would brute force a passphrase in the first place). Wow, good to know. I can see why the persistent storage must be deleted (thankfully the clone option should work for this situation). > To investigate further, can you verify the path $HOME/.local/share/bails/b exists? Yes, it exists. But so does $HOME/.local/share/Bails/b (Title case Bails). > dotfiles/.local/share/bails/b and tell me if that file exists if the first one does not As I mention just above, I did have the ...bails/b & .../Bails/b paths. Regarding dotfiles, I don't see anything in my dotfiles folder. I can't access /live/persistence/TailsData_unlocked with 'sudo', as I followed Tail's recommendation to not set up an Administrator password. — Reply to this email directly, [view it on GitHub](#88 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ARQZ6F2RPYWDZOAJKCSSZQDXZ5ZIHANCNFSM6AAAAAA4TLO4JY). You are receiving this because you commented.Message ID: ***@***.***>

[BenWestgate]

You can access dot files from the sidebar of the file explorer or the Places menu “Dotfiles”. That’s the actual persistent data, the stuff in amnesia are shortcuts to it that Tails creates. How to view dot files here: https://tails.net/doc/persistent_storage/configure/index.en.html#index13h2

…

On Mon, Sep 11, 2023 at 15:39, extrapockets ***@***.***(mailto:On Mon, Sep 11, 2023 at 15:39, extrapockets <<a href=)> wrote: > So you're ACK, the passphrase requirements for Wallet Encryption / Seed backup passphrase should be the same as what is recommended (but not enforced) for Persistent Storage? ACK. If users can use their favorite <50bit password and get away with it, many unfortunately will (as I did during the initial install). > I don't know what passphrase users gave to Persistent Storage, that's why I have to ask for it right afterwards to start the spaced-repetition training. I had closed bails immediately after cloning it via terminal to avoid the spaced repetition warnings (they had previously froze my Computer during a Bitcoin Core blockchain sync while I was away from the computer for a few days, as noted in [this comment](#50 (comment)) in [this issue](#50). So makes sense that I ended up using a password that did not have enough entropy for bails. > And worse, changing the passphrase on flash memory doesn't erase the old passphrase's ability to unlock your data, so it's not increasing security against an adversary with forensic tools (tends to be the same one who would brute force a passphrase in the first place). Wow, good to know. I can see why the persistent storage must be deleted (thankfully the clone option should work for this situation). > To investigate further, can you verify the path $HOME/.local/share/bails/b exists? Yes, it exists. But so does $HOME/.local/share/Bails/b (Title case Bails). > dotfiles/.local/share/bails/b and tell me if that file exists if the first one does not As I mention just above, I did have the ...bails/b & .../Bails/b paths. Regarding dotfiles, I don't see anything in my dotfiles folder. I can't access /live/persistence/TailsData_unlocked with 'sudo', as I followed Tail's recommendation to not set up an Administrator password. — Reply to this email directly, [view it on GitHub](#88 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ARQZ6F2RPYWDZOAJKCSSZQDXZ5ZIHANCNFSM6AAAAAA4TLO4JY). You are receiving this because you commented.Message ID: ***@***.***>

[BenWestgate]

I changed the check that causes persistent-setup to ask for the passphrase in your unique situation to not ask if bitcoin-core has been downloaded by bails and stored in dotfiles/.local/share/bitcoin-core before.

The second part of this issue, "able to create wallet with a weak passphrase", I'll open an upstream issue for on https://github.com/benwestgate/bails-wallet so I remember to include a passphrase strength check in addition to the length check.