Optional BIP39 passphrase at wallet creation and restore

[tdroxler]

In order to secure a bit more the mnemonic, we can already do it in the backend https://github.com/alephium/alephium/blob/975b343312a0513d3023399d4761f7ba0fb11fb5/wallet/src/main/scala/org/alephium/wallet/api/model/WalletCreation.scala#L26 basically this passphrase change the seed for a given mnemonic. So if someone steal the 24 words, he would still need to know that passphrase.

[polarker]

I am a bit against this proposal. I think that creation should go without a mnemonic and restorisaztion should go with a provided mnemonic always. Am I missing anything?

[nop33]

@tdroxler you are referring to the so-called 25th word (aka passphrase) which given the 24 words it creates a new wallet, correct? (similar to Ledger: https://www.ledger.com/academy/passphrase-an-advanced-security-feature)

Since this would be an advanced feature, an idea would be that it doesn't need to be part of the wallet creation workflow. It could be found in the settings of the wallet (same as in Ledger).

[polarker]

Sorry, forgot my brain fart 😓 It was about mnemonic passphrase!

[nop33]

I have many questions on how to implement this!

Supposing we want a similar implementation as Ledger's hardware wallet, where using a passphrase essentially "unlocks" a new wallet.

Creating a passphrase

I suggest that the creation of a passphrase takes place AFTER the initial wallet has been created.

Click here to see mockups

Step 1	Step 2
We could add a button in the "Accounts Settings" modal	Clicking the button will open another modal. Here, the user enters their passphrase and the password that they can use to log in to their wallet.

Accessing the new wallet

Nothing changes here. The user can simply choose their normal account and enter the new password which will unlock the new wallet.

Restoring wallet with passphrase

I haven't thought this one through yet, but I think having the above things implemented is enough. All the user has to do to restore a wallet with 24 words + a passphrase is to:

1. Restore the wallet normally, using their 24 words
2. Access the Accounts Settings page
3. Attach their passphrase and create a new password
4. Access the wallet

Attaching the same passphrase to the same 24 words should generate the same wallet, right? It's deterministic.

Blog post

I think it makes sense to write a blog post to explain it, similar to Ledger's one.

[polarker]

@nop33 As far as I see, the article is about the theory side, not about implementation. Could you check how it's implemented in Ledger? Shall we copy Ledger? How is other desktop wallet supporting passphrase?

[polarker]

Please checkout with Thomas on wallet design details. The ataching thing proposed is not doable as far as I see

[nop33]

As far as I see, the article is about the theory side, not about implementation.

Sorry @polarker, I meant to post this article with the step by step process: https://support.ledger.com/hc/en-us/articles/115005214529-Advanced-passphrase-security?docs=true

How is other desktop wallet supporting passphrase?

I found here a list of wallets that support BIP39, I will investigate.

These are some software wallets that support the passphrase feature (source):

Mobile wallets

• Samourai Wallet
• Coinomi
• Mycelium
• Exodus

Desktop wallets

• Wasabi Wallet (Wasabi refers to this as your wallet password)
• Coinomi (can only restore BIP39 with passphrase, cannot create wallet with passphrase)
• Electrum
• Exodus

Web wallets

• Zillet (Referrs to BIP39 passphrase as a "password based" wallet type)

[nop33]

After discussing several security and UX approaches with @tdroxler & @mvaivre, we agreed that we want to find the sweet spot between high security and great UX. What we want is:

1. Help users protect themselves in case their 24 words get stolen
2. Help users protect themselves in case of threat (5$ wrench attack) to reveal 24 words and passwords (give them the benefit of plausible deniability)
3. Not confuse users with complicated UI and UX

User flows

Creation of account user flow

When creating a new account, the user has the option to secure this account with an optional passphrase. Passphrase input is hidden behind an “advanced options” expandable section (ie. complexity is hidden by default).

Login user flow

The login screen allows the user to:

• Choose the account they want to login
• Enter their password
• Optionally enter a passphrase

Login Scenarios

1. If a passphrase does not exist for this account and the user does not enter a passphrase, the wallet unlocks (current flow).
2. If a passphrase does not exist for this account and the user enters a passphrase, an error message saying "No account associated with this passphrase" appears.
3. If a passphrase exists for this account and the user enters the correct passphrase, the passphrase-enabled-wallet unlocks.
4. If a passphrase exists for this account and the user enters a wrong passphrase, an error message saying "No account associated with this passphrase" appears. It is important to not say "Wrong passphrase" because this defeats the benefit of plausible deniability, by revealing that the user has used the passphrase optional feature and cannot deny it.
5. If a passphrase exists for this account and the user does not enter a passphrase, the "decoy" wallet unlocks. The user can decide whether they want to load some small funds to the decoy wallet or not.

Wallet restore/import user flow

• When importing a wallet using the mnemonic 24 words, the user has the option to provide a passphrase as well.

Security & UX considerations

Higher security

Some of the desktop wallets that I have tested (Wassabi wallet, Coinnomi wallet) allow that if you enter a different passphrase, a new empty wallet will be created.

Even though this is the best approach regarding security, we do not like it, because we are afraid that it will confuse our users a lot (aka "Where did my funds go, I think my passphrase is correct?").

Ledger and other hardware wallets allow the association of multiple passphrases to the same set of 24 words. We think that even though this increases security a lot, it will complicate the UX and UI. Thus, we agree to allow 1 passphrase per wallet.

Least confusing UX

The least confusing UX would be to not allow a passphrase-enabled-wallet to unlock a "decoy" wallet when no passphrase is entered at login, and instead show a message "Please, enter the passphrase associated with this account".

If we do that, however, we cannot give the user the benefit of plausible deniability (Requirement 3) and they can easily become victims to the 5$ wrench attack.

How other desktop wallets implement BIP39 with passphrase

Electron wallet

Electon wallet creation user flow

Give a name	Choose type	Choose create	Click "Options" and "Extend with custom words"	Enter passphrase

Electron wallet restoration user flow

Give a name	Choose type	Choose "I have seed"	Enter seed	Click "Options" and "Extend with custom words"	Enter passphrase

Coinomi wallet

They only allow restoration with a passphrase (no creation)

Wasabi wallet

They called it "wallet password" and you cannot have a wallet without it.

Wasabi wallet creation user flow

Enter name and passphrase	Confirm

Wasabi wallet restoration user flow

[polarker]

@nop33 LGTM. Please chat with @tdroxler regarding how to store and verify passphrase

[tdroxler]

@polarker yep we discussed it yesterday too, we will use the same double hash as in the node. The seed won't be store anymore in the secret file either and will be computed on creation/restore/unlock and store in memory. We will now have the same level of security as in the node, maybe even more as we well have this "decoy" wallet, which I found a great idea, maybe we could do the same in then node.

@nop33 Awesome work and resume, it's also super sweet to have all the screenshots of others wallet! Great investigation 🚀