Lesson 4 — Passphrases: the 25th word done right
A BIP-39 passphrase isn't a password — it's an extra ingredient that creates an entirely different wallet. Today: what it does cryptographically, what plausible deniability really gets you, and the fatal mistake.
The BIP-39 passphrase is one of the most misunderstood features of modern wallets. It's often called the '25th word', which is technically wrong but useful as an intuition. Used well, it adds a factor an attacker must obtain on top of the seed. Used badly, it is the most common way self-custody users lose their funds — not to thieves, but to themselves.
Cryptographically, the BIP-39 passphrase is the salt in a PBKDF2 key-derivation function. The 12-or-24-word mnemonic provides the entropy; the passphrase is mixed in via 2,048 rounds of HMAC-SHA512; the output is the binary seed that drives every key in the wallet. Change one character of the passphrase, and you derive an entirely different binary seed — which means an entirely different wallet, with entirely different addresses, with entirely different (probably zero) balances.
The two practical implications follow directly. First: the passphrase isn't 'extra protection for one wallet' — it is 'the input that selects which wallet you get from this seed.' Every distinct passphrase gives you a distinct wallet. No passphrase (or empty passphrase) gives you the 'standard' wallet most software defaults to. Second: the passphrase is never stored anywhere. The wallet doesn't 'check' it; it just uses it. Type a different passphrase and you'll see a different empty wallet, not an error.
This second property is what 'plausible deniability' rests on. If an attacker compels you to unlock your hardware wallet, you can unlock the no-passphrase wallet — which holds your decoy balance — without revealing that a passphrase-protected wallet exists. There is no flag on the device that says 'one passphrase has been used.' The hidden wallet is, cryptographically, just another point in an infinite space of possible wallets the seed could derive.
The honest limit of plausible deniability is that a sophisticated attacker knows hidden wallets exist. If they know you might have one, demanding the no-passphrase wallet first isn't where they stop. They'll keep going. Plausible deniability protects you against attackers who don't know about the feature — which is many but not all. It does not, on its own, protect you against a determined and informed attacker.
Storage practice for passphrases is the inverse of storage practice for seeds: keep them physically separated. The seed alone, without the passphrase, unlocks only the decoy wallet (if you have one) or no wallet (if you don't). The passphrase alone, without the seed, unlocks nothing. An attacker needs both. Many users store the seed at home and the passphrase in a different physical location — a bank deposit box, a trusted relative's safe, a separate metal backup — so that no single compromise yields the wallet.
The fatal mistake is forgetting the passphrase. We have seen users with substantial holdings store the seed perfectly and treat the passphrase as 'something I'll always remember' — only to have a head injury, a long illness, or simply months of disuse erase it. The passphrase is exactly as recoverable as a forgotten brain wallet: not at all. If your inheritance plan covers the seed but not the passphrase, your heirs inherit the decoy wallet and nothing else. Whatever scheme you use, the passphrase needs an out-of-band, retrievable backup — just not co-located with the seed.
Example
A common pattern that works well: a user keeps their 24-word seed in a metal backup at home, and stores their passphrase as an indirect clue inside a bank deposit box — for example, a card that reads 'middle name of mother's first dog, in lowercase, plus the year you were married.' The seed alone is useless without the passphrase; the passphrase clue is useless without context only the user (or their executor, with the letter-of-last-instructions covered in Lesson 7) would know. Neither location's compromise yields the wallet. The wallet survives plausible theft scenarios; it also survives the user's own forgetfulness, because the clue is reconstructable.
Common mistakes
- Treating the passphrase as a 'password' that simply unlocks the wallet. It doesn't — it selects which wallet the seed derives.
- Storing the passphrase right alongside the seed. Doing so collapses two factors into one.
- Choosing a passphrase you 'will always remember' with no recoverable backup. Memories fade; injuries happen; the passphrase has no recovery flow.
- Believing plausible deniability protects you against an attacker who already knows hidden wallets are a feature.
- Forgetting that an empty passphrase still produces a valid wallet — meaning your decoy wallet's existence is part of the design, not a bug.
Check your understanding
What is a BIP-39 passphrase doing, cryptographically, when you use one?
Key terms covered
Sources & further reading
- PrimaryBIP-39 — Passphrase section
The 'From mnemonic to seed' section specifies the PBKDF2 derivation including passphrase as salt.
- SecondaryTrezor — Passphrases documentation
Vendor documentation of passphrase + hidden-wallet workflow.
- SecondaryLedger — Advanced passphrase security
Vendor documentation of the passphrase feature.
We prioritise primary sources. Where a topic moves quickly (regulation, security incidents), we re-check sources on the cadence shown by the page's "Next review" date.