What is a Passphrase?

Introduction

Passphrase in wallet systems means an optional secret that is combined with your recovery phrase when deriving wallet keys. The important point is easy to miss: a passphrase usually does not act like a normal app password that unlocks something already stored. Instead, it changes the cryptographic input, so the wallet generated with passphrase A is a different wallet from the wallet generated with passphrase B, even if the recovery phrase is identical.

That difference explains both why passphrases are useful and why they are dangerous. A normal password can often be reset because the underlying account still exists somewhere else. A wallet passphrase usually cannot be reset, because there is no separate account database holding the “real” keys for you. The keys are derived from your inputs. Change the inputs, and you derive different keys.

This is why experienced self-custody users sometimes treat a passphrase as a second layer on top of a seed phrase, and why beginners are often warned not to turn it on casually. If you understand the mechanism, the tradeoff becomes clear: a passphrase can protect funds if your recovery phrase is exposed, but it can also make your own backup incomplete if the passphrase is lost, mistyped, or remembered incorrectly.

How does a wallet passphrase change which wallet is derived?

The simplest mental model is this: your recovery phrase is not itself the wallet. It is human-readable input used to derive a binary seed, and that seed is then used to derive the wallet’s master keys and all child addresses.

In BIP-39-style wallets, the recovery phrase and passphrase are fed together into a key-derivation process. If no passphrase is supplied, the empty string "" is used.

If a passphrase is supplied, even a very small change produces a different binary seed.

• uppercase instead of lowercase
• an extra space
• a typo

That different seed then feeds into the deterministic wallet tree, producing a different master key and therefore different accounts and addresses.

So when wallet interfaces say things like “hidden wallet,” “passphrase wallet,” or “25th word,” they are gesturing at the same underlying mechanism: the passphrase changes derivation. The phrase “25th word” is only an analogy. It is useful because it conveys that the passphrase behaves like an additional required secret, but it can also mislead. It is usually not literally one word, and in standards like BIP-39 it is not appended to the mnemonic as another mnemonic word. It is a separate input to the seed-derivation function.

That distinction matters operationally. If someone has your 12 or 24 mnemonic words but not your passphrase, they may recover a valid wallet; just not necessarily your intended one. Conversely, if you have memorized a passphrase but lost the mnemonic, the passphrase alone is useless. The derived wallet depends on both inputs together.

How does BIP-39 derive a wallet seed from a mnemonic and passphrase?

Most mainstream wallet discussions of passphrases refer to the BIP-39 mechanism. Here is the core process.

A mnemonic sentence (the 12, 18, or 24 recovery words) is turned into a binary seed using PBKDF2, a password-based key derivation function. In this process, the mnemonic is used as the password input, and the salt is the string "mnemonic" concatenated with the user’s passphrase. Both the mnemonic and the passphrase are normalized as UTF-8 NFKD before derivation. The function uses 2048 iterations of HMAC-SHA512 and outputs 64 bytes, or 512 bits, of seed material.

In compact form, the rule is: same mnemonic + same passphrase = same seed. Change either input, and you get a different seed.

That seed is then handed off to the hierarchical deterministic wallet scheme defined by BIP-32 or similar systems. BIP-32 takes the seed S, computes I = HMAC-SHA512(Key = "Bitcoin seed", Data = S), splits I into two 32-byte halves, and uses one half as the master private key material and the other as the master chain code. From there, the wallet can derive an entire tree of accounts, receiving addresses, and change addresses.

The crucial consequence is that the passphrase does not sit outside the key tree as a separate access control layer. It sits upstream of the entire tree. It changes the seed, which changes the master key, which changes every descendant key.

A worked example makes this more concrete. Imagine Alice writes down a 24-word mnemonic and initializes a wallet without any passphrase. Because BIP-39 treats the absent passphrase as the empty string, her wallet is derived from mnemonic + "". Later, she restores the same 24 words in another wallet app but types orchid as a passphrase. The app is not “unlocking” her previous wallet with an extra password. It is deriving a new seed from mnemonic + "orchid", then generating a new master key tree from that seed. The result is a valid wallet with valid addresses; very likely empty, unless she had previously used that exact passphrase. If she then mistypes orchad, she gets yet another valid wallet. The software cannot detect that this was a typo by looking at the derived keys alone, because every passphrase produces a syntactically valid seed.

This property is why passphrases feel counterintuitive at first. Most users expect a wrong password to fail immediately. In a passphrase-based HD wallet, the more common behavior is different: the wrong passphrase often succeeds in deriving a different wallet.

Why do wallets offer passphrases and what security benefits do they provide?

The problem a passphrase solves is straightforward: a mnemonic written on paper is a single secret. If someone finds it, they may be able to derive the wallet and spend the funds. A passphrase allows the user to require a second secret before the intended wallet appears.

This can be useful in a few distinct ways, but they all come from the same mechanism. Because the passphrase changes the seed, possession of the mnemonic alone is no longer sufficient to derive the protected wallet. In practice, that means a photographed backup, a copied seed phrase, or even a coerced disclosure of only the mnemonic may not expose the funds stored behind the passphrase-derived wallet.

The same property also creates plausible deniability, a feature explicitly noted in BIP-39. Every passphrase yields a valid wallet, so there is no obvious cryptographic marker that says, “this mnemonic definitely has another hidden wallet behind passphrase X.” A user could keep small amounts in the no-passphrase wallet and larger amounts in a passphrase wallet. That does not make coercion safe in any broad sense (real-world threats are messier than protocol design) but it explains why the idea exists.

There is also a more ordinary use: segmentation. A person may derive different wallets from the same mnemonic by using different passphrases for different purposes, such as personal savings versus active trading funds. Mechanically, this works because each passphrase creates a different root seed. Operationally, though, it raises complexity fast, which is why many users are better served by separate seed phrases or separate hardware devices if they need clean compartmentalization.

What are common misunderstandings about passphrases, PINs, and storage passwords?

The biggest misunderstanding is confusing three different things that are all casually called “passwords.”

First, there is the wallet passphrase in the BIP-39 sense: the optional secret mixed into seed derivation. This changes which wallet exists.

Second, there may be a device PIN or app unlock code. That protects access to the hardware device or software interface, but it does not by itself define the wallet’s key material.

Third, there may be a storage-encryption password used to encrypt locally stored keys or keystore files. This protects data at rest on a computer or phone, but again it is conceptually separate from mnemonic-to-seed derivation.

Some ecosystems make this distinction explicit. In the Cosmos SDK, for example, the BIP-39 passphrase used in seed derivation is separate from the passphrase used to encrypt persisted private keys in the keyring. Substrate tooling makes a similar distinction between a derivation password in the URI syntax and any keyring pair password. These are not interchangeable. If you recover the wrong kind of “password,” you may still not get the intended keys.

Another common misunderstanding is thinking that a hardware wallet stores the passphrase for you. Some products explicitly do not. Trezor, for example, warns that the device does not store the passphrase and that the user must enter it each time. That is not an incidental UI choice. It reflects the fact that the passphrase is treated as secret input to key derivation rather than as a recoverable account preference.

A third misunderstanding is assuming that if the passphrase is forgotten, the wallet manufacturer can help recover it. In general, they cannot. If the wallet was derived from mnemonic + passphrase, and you know only the mnemonic, then you do not possess the full derivation input. Unless the passphrase is weak enough to guess or partially remembered well enough to search for, the intended wallet is effectively inaccessible.

Why can a mistyped passphrase create a completely different wallet?

The same property that gives passphrases their security value creates their biggest operational risk. Because every passphrase derives a valid wallet, the system usually cannot tell the user, “that passphrase is wrong.” It can only show the wallet derived from what was entered.

This is why passphrase management failures are so common and so unforgiving. Case differences matter. Whitespace can matter. Character normalization can matter. In BIP-39, normalization is specified as UTF-8 NFKD precisely because text encoding and Unicode representation can otherwise create subtle incompatibilities. Two passphrases that look visually identical can, in poorly coordinated systems, encode differently. The standard tries to prevent that, but interoperability still depends on implementations following the same rules.

This is also why product docs often insist that passphrases are for advanced users. The cryptography is not the hard part. The hard part is human reliability under stress: writing it down exactly, restoring it years later, testing recovery before funding the wallet heavily, and understanding that there is no safety net if the record is incomplete.

A practical implication follows from first principles: if your backup plan says “I have my seed phrase written down, so I can always recover,” then adding a passphrase means that statement is no longer true. Your real backup becomes “I have the seed phrase and the exact passphrase.” Anything less is an incomplete backup.

Can passphrase-protected wallets be restored across different wallets and ecosystems?

The broad idea of “extra secret used during wallet derivation” appears beyond Bitcoin-style wallets, but the exact construction is not universal.

In BIP-39-compatible systems, many chains and wallets inherit the same mnemonic-plus-passphrase seed derivation. That is why the idea shows up across Bitcoin wallets, Ethereum wallets, Cosmos-based wallets, and many multi-chain products. Once a wallet uses BIP-39 mnemonics and standard seed derivation, the passphrase concept travels with it.

But neighboring ecosystems may define their own derivation conventions. Cardano’s Icarus format, for instance, supports an extra passphrase (sometimes called a mnemonic password) but uses different key-derivation details than BIP-39-to-BIP-32 wallets. Its annex describes PBKDF2 with HMAC-SHA512, 4096 iterations, and a 96-byte output before ed25519-specific bit-tweaking. The important lesson is not the numeric parameter difference by itself. It is that “passphrase” is a family resemblance term, not a guarantee of cross-wallet compatibility. The user-level idea may sound the same while the derivation algorithm differs.

Substrate provides another variation. Its SURI format can include a derivation password marked by ///, alongside hard and soft derivation path segments. That password affects derivation and is distinct from any keyring password used for local storage. Again, the user-facing concept is familiar (an extra secret required to derive the intended account) but the syntax and semantics belong to that ecosystem’s own tooling model.

This is where smart users often get tripped up by overgeneralization. If two wallets both say “supports passphrase,” that does not automatically mean you can restore one into the other unless they share the same mnemonic format, normalization rules, seed derivation, and path conventions. Interoperability is a stack, not a single checkbox.

What does PBKDF2 do for wallet passphrases and what are its limits?

PBKDF2 exists to make password or passphrase guessing more expensive. More precisely, it stretches human-chosen input into cryptographic key material using a salt and repeated computation. In BIP-39, the salt includes the fixed prefix "mnemonic" plus the passphrase, and the function runs 2048 rounds of HMAC-SHA512.

The mechanism matters because human secrets are usually much weaker than random cryptographic keys. If a passphrase were used directly, attackers could test guesses cheaply. A key-derivation function increases the work required for each guess. That does not make a weak passphrase strong, but it raises the cost of large-scale guessing.

Here the limitation is as important as the benefit. A passphrase’s security still depends heavily on the passphrase itself. If the passphrase is short, common, patterned, or drawn from a small search space, an attacker who has the mnemonic can attempt offline guesses. Tools such as BTCRecover exist precisely because many real-world “lost passphrase” cases are recoverable only when the user remembers enough structure; a likely word, a date pattern, a handful of variations, maybe capitalization habits. That is good news for accidental loss recovery, but it also reveals the boundary: if recovery tools can search your likely guesses, so can an attacker.

In other words, the passphrase’s value is not magical. It is strongest when it adds substantial unpredictability; it is weakest when it adds only ceremony.

General guidance from memorized-secret standards also helps here. Strong passphrases tend to benefit more from length and unpredictability than from rigid composition tricks. Arbitrary forced complexity rules often produce secrets that look complicated but are still guessable. At the same time, wallet passphrases are unusual because recoverability matters more than in ordinary web login systems: there is usually no reset flow. So the design problem is not merely “maximize entropy.” It is “maximize entropy without making your own recovery impossible.”

How should I manage and test a wallet passphrase safely?

The right way to think about a wallet passphrase is as part of the backup, not as a convenience feature.

If you choose to use one, the first requirement is exact recording. Since passphrases are often case-sensitive and can be sensitive to spaces and character choice, you need a canonical written record. Relying on memory alone is a gamble unless the funds are small enough that total loss would be acceptable.

The second requirement is recovery testing. A passphrase setup should not be considered complete when the wallet opens successfully the first time. It should be considered complete when you can restore it from the mnemonic and the written passphrase on a separate device or clean environment and verify that you reach the expected addresses. This step catches the most dangerous class of error: an unnoticed typo in the original record.

The third requirement is understanding what threat you are actually defending against. If the main risk is malware on your everyday computer, a hardware wallet and careful transaction verification may matter more than a passphrase. If the main risk is physical exposure of your written seed backup, a passphrase can materially improve security. If the main risk is your own future confusion, a passphrase may worsen it. Security is always relative to a threat model, and passphrases are no exception.

It is also wise to avoid mixing concepts. Do not assume your device PIN, wallet app password, seed phrase, and passphrase can substitute for one another. They protect different layers. Good wallet hygiene starts with knowing which secret does what.

What is a wallet passphrase in one sentence?

A wallet passphrase is an optional secret that is combined with your recovery phrase to derive a different seed and therefore a different deterministic wallet; that is why it can protect funds if your seed phrase is exposed, and also why losing it can permanently strand those funds.

Conclusion

The core truth about a passphrase is simple once you see it: it is part of derivation, not just part of access control. That is the reason it creates genuinely separate wallets from the same mnemonic, the reason it can provide plausible deniability and extra protection, and the reason it is so unforgiving when mishandled.

If you remember only one thing, remember this: a seed phrase with a forgotten passphrase is not a complete backup. In self-custody, the system cannot recover cryptographic inputs you did not preserve. The passphrase is powerful for exactly the same reason it is dangerous; the wallet is derived from what you know, not restored from what someone else stores for you.

How do you secure your crypto setup before trading?

Secure your crypto setup before trading by treating your mnemonic and any passphrase as a single, testable backup and by validating end-to-end signing. On Cube Exchange you retain non-custodial control (MPC/threshold keys); use these checks to avoid irreversible loss and to confirm your signing and transfer flows before funding large positions.

1. Record your mnemonic and any passphrase exactly. Include case, spaces, and special characters, then store copies in two physically separate secure locations.
2. Restore the wallet from that recorded mnemonic plus passphrase on a different device or clean environment. Verify the first receiving address or account matches the one you expect.
3. Sign and broadcast a small test deposit or trade using your Cube non-custodial account or a hardware signer to confirm keys and on-chain behavior.
4. After the test clears, fund the account and place your trade. Monitor chain confirmations or the exchange's deposit credit rules before increasing exposure.