Blog

A cryptocurrency holder with significant assets faces a practical security problem: a single recovery seed phrase, even if stored offline, represents a single point of failure. If a device is stolen, a backup is compromised, or a key is exposed through accident or malware, all funds derived from that seed become vulnerable. Hardware wallets from Ledger and Trezor address this partly by keeping private keys isolated from internet-connected computers, but the recovery phrase itself still generates a complete wallet. A passphrase feature—sometimes called a hidden wallet or advanced passphrase—creates a second layer. By adding a memorized passphrase to the seed during key derivation, a user can generate an entirely different set of addresses and private keys. That second wallet exists only when the correct passphrase is entered; without it, the attacker has access to an empty or decoy wallet.

Rabby Wallet, a self-custodial browser extension and mobile application for Ethereum and EVM-compatible networks, integrates with hardware wallets and supports this multi-wallet architecture. The wallet’s design emphasizes transaction preview and risk alerting before signing, and its compatibility with Ledger and Trezor devices means a user can configure multiple passphrases within the same browser, each unlocking different account hierarchies. This creates both security and operational complexity. The passphrase is not a password recovery tool; it is a cryptographic secret that must be remembered or stored with care. If forgotten, the accounts derived from it become inaccessible, even with the original seed. If stored insecurely, it defeats the isolation it was meant to provide.

How passphrases change the account derivation model

A standard BIP39 seed phrase—typically twelve or twenty-four words—encodes entropy that can generate an unlimited number of hierarchical deterministic accounts. Each account has its own public key, private key, and receiving addresses. Without any passphrase, all accounts derive from the same seed following a standard path, such as m/44’/60’/0’/0/0 for Ethereum. A user or an attacker with the seed phrase can regenerate every account. A passphrase (also called a BIP39 passphrase or hidden wallet) modifies this process at the root level. Instead of deriving accounts directly from the seed, the seed plus the passphrase together generate a master key. That modified master key then produces accounts using the same hierarchical structure, but the addresses and private keys will be completely different from those generated without the passphrase.

The security benefit is separation. If an attacker obtains the original seed through a backup theft or device compromise, they will see only the accounts created without the passphrase—often the user’s standard wallet. A second, third, or tenth passphrase creates separate account families, each inaccessible without that specific passphrase. A user could keep most funds in an account protected by a long, complex passphrase stored in a separate location, while another account with a shorter passphrase holds spending money for regular interaction. The attacker would have to know not just the seed, but also the passphrase and which passphrases the user employed.

Rabby’s integration with hardware wallets preserves this model. When a Ledger or Trezor device is connected, the device itself handles key derivation. The passphrase is entered during the connection process or before signing transactions. The device generates the derived accounts and never exposes the master key or the seed to the browser extension. Rabby displays the accounts associated with the current passphrase and lets the user select which addresses to use for sending and receiving. If the user disconnects the device, changes the passphrase, and reconnects with a different one, Rabby will show a different set of accounts derived from the same hardware seed but with different cryptographic roots.

This architecture means the passphrase must be entered correctly every time the wallet is used. Typos matter. A single incorrect character generates an entirely different master key and set of accounts. Some users keep a memorized passphrase and store a backup offline in a separate location—a paper document in a safe, a safety deposit box, or distributed across multiple trusted people. Others use shorter passphrases that are easier to type but less secure against brute-force attacks if the seed is already exposed. There is no single best practice; the choice depends on the user’s memory, discipline, storage options, and risk tolerance.

Ledger and Trezor passphrase behavior within Rabby

Ledger devices support BIP39 passphrases natively. When a user connects a Ledger to Rabby, they can optionally enter a passphrase in the Ledger’s own interface or in the Ledger Live application, and then Rabby will recognize the accounts derived from that passphrase. Ledger’s approach is to require the user to set a PIN and enter it on the device, then optionally unlock the passphrase feature within the device’s settings. Once enabled, the device prompts for the passphrase during connection, ideally on the device’s screen itself to avoid typing it on a potentially compromised computer.

Trezor has a similar design, with the Trezor device prompting for the passphrase during the connection process. If a user has configured a passphrase in Trezor’s wallet settings, the device will request it when connected to any application, including Rabby. Both devices keep the passphrase entry on the device screen (or in the device firmware) as much as possible to reduce exposure to the browser extension or operating system. However, the exact flow depends on the device firmware version and the browser extension’s implementation. A user connecting a Trezor to Rabby may be prompted to enter the passphrase in the Rabby interface itself, depending on whether the device is configured to prompt or the extension is configured to request it.

The practical effect in Rabby is that the browser extension displays a list of accounts derived from the currently active passphrase. If the user enters a different passphrase and reconnects, a new set of accounts appears. Rabby does not require storing the passphrase in the extension itself; the extension only manages which accounts are visible and which ones the user selects for transactions. Each time the user signs a transaction, Rabby initiates the hardware wallet connection, and the device handles the actual signing. The device never reveals the private key to Rabby. This architecture means a compromised Rabby extension or a malicious browser cannot extract the passphrase or sign transactions without the physical device.

Multi-wallet architecture: organizing accounts across passphrases

A user with a Ledger or Trezor can create a deliberate account hierarchy using multiple passphrases. One common pattern is to create a primary wallet with a strong, stored passphrase containing the bulk of funds, and a secondary wallet with a shorter, memorized passphrase for active spending. When connected to Rabby, the user can toggle between passphrases by disconnecting the device, re-entering a different passphrase, and reconnecting. Rabby will then show accounts associated with the new passphrase.

Another pattern is to use passphrases for account segregation by purpose. One passphrase might derive accounts used exclusively for DeFi interaction—staking, lending, token swaps—where the private key is exposed to smart contracts. A different passphrase might derive accounts used only for receiving funds and long-term holding, which never interact with untrusted contracts. If the DeFi account is compromised through a smart contract vulnerability, a rug pull, or a malicious transaction, the funds in the other passphrase-protected account remain isolated. Rabby’s transaction preview and risk alert features add another layer of protection by highlighting suspicious contract interactions before the user signs.

Some users create a decoy wallet from a short, easy-to-guess passphrase with minimal funds. If a device is stolen or an attacker coerces the user to unlock it, the attacker finds only the decoy wallet. The real funds remain in accounts protected by a passphrase stored in a separate location. This approach trades convenience against security; the decoy wallet must be maintained and monitored to appear genuine, and the user must remember not to accidentally consolidate funds across passphrases in a way that reveals the decoy.

Setup and operational workflow in Rabby

Rabby works with multiple Chromium browsers, including Chrome, Brave, and Edge, which simplifies installation and updates. Once the extension is installed, a user connects a hardware wallet by clicking the connection option, selecting Ledger or Trezor, and following the pairing prompt. The device will ask to confirm the connection. If a passphrase is enabled on the device, the device will prompt for it at this stage, or Rabby will display a field for passphrase entry depending on the configuration.

The user selects one or more accounts from the list displayed and adds them to Rabby’s address book. Rabby then shows balances, transaction history, and available DeFi interactions for those accounts. When the user initiates a transaction, Rabby generates a preview that shows the contract being called, the amount being transferred, and any detected risks—such as approving an unknown contract or sending to a suspicious address. The user reviews this preview on their computer screen, then confirms the transaction on the hardware device itself. The device shows the essential details again and requires physical confirmation (a button press on the Ledger or Trezor).

If the user wants to access accounts protected by a different passphrase, they must disconnect the device, re-enter the passphrase, and reconnect. This is inconvenient for frequent switching but intentional. It ensures the user must actively choose which passphrase to use and prevents accidental mixing of accounts. Some users maintain separate browser profiles or even separate computers for different passphrases, which further isolates the wallets and reduces the chance of operational mistakes.

Risk management and passphrase storage

The passphrase is a cryptographic secret with the same security requirements as the seed itself. If lost, it cannot be recovered. If exposed, it compromises the accounts derived from it. Many users treat the passphrase as a backup secret, storing it in a physical safe, a lawyer’s document locker, or a secure storage service. Some memorize a passphrase, which eliminates the risk of theft but creates the risk of forgetting it. A common middle ground is to store a hint—not the passphrase itself, but a personal clue that helps the user recall it—in a secure location.

A written backup of the passphrase should never be stored near the seed phrase itself. If both are discovered together, the security advantage of the passphrase disappears. Some users split the passphrase across multiple physical documents and store them in different locations, or use a secret-sharing scheme where no single document reveals the passphrase. Others create a passphrase derived from a personal fact—a birth date, a pet’s name, a memorable date—that only they are likely to know. This approach makes the passphrase easier to remember but weaker against targeted attacks from someone who knows the user’s personal history.

Rabby itself does not store passphrases. The extension is a non-custodial wallet, meaning it never holds the seed or the passphrase. The hardware device holds the seed, and the passphrase is entered by the user each time. This design prevents Rabby from being compromised and exposing the passphrase or seed. However, it also means the user must manage the passphrase independently. If Rabby is reinstalled or removed, the passphrase is not lost—it is still required to access the accounts—but the user must re-enter it to reconnect the hardware wallet.

Common operational mistakes and how to avoid them

A frequent mistake is entering an incorrect passphrase and not realizing it. If a user enters “MySecurePass1” instead of “MySecurePass1!” (missing the exclamation mark), the hardware device will derive a completely different set of accounts. Rabby will display those accounts as if they are the correct ones, and the user may try to find “missing” funds. The funds are not missing; they are in accounts derived from the correct passphrase. To avoid this, some users enter the passphrase, note the receiving addresses displayed, and verify them against a previous backup before making any transactions.

Another mistake is storing the passphrase in a password manager that is synced across devices or backed up to a cloud service. If the password manager is compromised, the passphrase is exposed. Some users argue that the password manager is as secure as their email or cloud account, so syncing is acceptable. Others keep the passphrase in a separate, offline record. The best approach depends on the user’s threat model and the value of the funds protected.

A third mistake is using the same passphrase across multiple hardware devices. If the user has two Ledgers, one as a backup and one for daily use, they might set the same passphrase on both for convenience. This creates a single point of failure: if the passphrase is discovered, both devices are compromised. Using different passphrases on each device increases security but adds complexity and makes recovery harder if one device fails and the other is unavailable.

Testing the passphrase recovery process is essential but often skipped. If a user writes down a passphrase and stores it securely, they should periodically verify that they can actually recover it—by traveling to the storage location, retrieving the document, and using it to unlock the wallet. This test should use a small amount of funds or a test device to avoid accidentally mixing wallets or losing access. A user who has never tested recovery and then loses the device containing the passphrase stored in memory faces a difficult choice: reveal the passphrase to a trusted person for safekeeping, commit it to a written backup that contradicts the storage plan, or accept the risk of permanent loss.

Rabby’s transaction preview as a complementary security layer

Passphrase-based account separation addresses key compromise at the recovery-phrase level. Rabby’s transaction preview and risk alerting address compromise at the interaction level. When a user attempts to approve a smart contract or send tokens, Rabby simulates the transaction and displays what will happen. If the contract is unknown, newly deployed, or has suspicious patterns, Rabby alerts the user. Some alerts are warnings—informing the user of potential risk without blocking—while others might be blockers if the contract is flagged as malicious.

This approach is valuable because it catches mistakes and social engineering. A user might intend to approve a legitimate contract but accidentally paste a malicious contract address from a phishing email. Rabby’s preview will show that the contract is unknown or recently deployed. A user might receive a message claiming to be from a DeFi protocol, asking them to approve token spending to “fix” a transaction error. Rabby’s preview will show the actual contract and the amount of spending approved, revealing the scam. Transaction preview cannot replace passphrase security—it protects against different classes of attacks—but together they reduce risk across multiple vectors.

When passphrase security makes sense and when it is overkill

For a user holding a significant portion of their net worth in cryptocurrency, passphrase protection is a reasonable security investment. The attacker must not only compromise the backup seed but also guess or discover the passphrase. For a user holding a small amount or learning to use cryptocurrency, the added complexity may introduce more operational risk than it prevents. A user who keeps $100 in an active Rabby wallet and has a cold backup of the seed does not necessarily benefit from a passphrase; the focus should be on securing the backup seed itself.

Passphrase protection is also valuable when the seed and the device may be exposed to different threats. An employee using a hardware wallet in a corporate environment might store the seed at home in a safe, but if the device is lost or stolen at the office, a passphrase provides additional protection. An individual living in a region with political instability might separate the seed and passphrase geographically—the seed in one location, the passphrase in another—to protect against coercion or confiscation. A person managing funds for a family member might store the seed and passphrase separately, with the passphrase held by a lawyer or trusted advisor to prevent unilateral spending.

The decision to use a passphrase should flow from a specific threat model rather than from a general recommendation. Asking “What would an attacker need to do to steal my funds?” clarifies whether a passphrase actually raises the bar. If the threat is a stolen backup stored in a home safe, a passphrase is valuable. If the threat is malware on the device, passphrase protection offers little help—the malware can observe the passphrase as it is entered. If the threat is accidental loss, a passphrase increases the risk of permanent loss if it is forgotten or destroyed. The right security model acknowledges these trade-offs rather than assuming more protection is always better.