Rabby Wallet Extension on Shared Family Computers: Isolating Accounts and Preventing Unauthorized Access

A household with multiple adults or teenage household members who use cryptocurrency faces a practical security problem: a single computer may need to support several independent wallets, but installing a browser extension creates a single entry point that could expose all accounts if one person’s password is weak or the device is physically compromised. The Rabby wallet extension, deployed across Chrome, Brave, Edge, and other browsers, makes it straightforward to connect to decentralized applications and manage assets on Ethereum and EVM-compatible chains. Yet that same convenience means that anyone with access to the device and browser can potentially view balances, initiate transactions, or access recovery information if proper isolation is not enforced.

The core question is not whether a self-custody wallet like Rabby can be safely shared on a device—it can—but rather what operating-system and account-management practices must surround it to prevent one family member from compromising another’s funds or recovery phrase. A technical understanding of how browser extensions store data, how operating-system user accounts isolate browser profiles, and how PIN or biometric authentication can gate wallet access is therefore as important as understanding the wallet’s own features. Most security breaches in shared-device scenarios occur not because the wallet software fails, but because the isolation layer between users is forgotten or misconfigured.

Operating-system user accounts as the foundation of wallet isolation

The Rabby wallet extension stores its data—including encrypted private keys and recovery phrases—within the browser’s profile directory. On Windows, this is typically under C:\Users\[Username]\AppData\Local; on macOS, it resides in ~/Library/Application Support. If two family members use the same Windows or macOS user account, they share the entire filesystem namespace, including the browser profiles and all extension data. This means that anyone logged into that account can access the browser, open the extension, and view balances or transaction history without needing to know the wallet password.

The first and most critical step is therefore to ensure that each person who holds cryptocurrency uses a separate operating-system user account on the shared computer. On Windows, this means creating a local or Microsoft account under Settings > Accounts > Family & Other People. On macOS, this is done through System Settings > General > Users & Groups. Each account receives its own filesystem, home directory, and browser profile storage. When a user logs into their account and installs or uses a browser, the extension data is stored in their own user profile directory, making it inaccessible to other users unless they log in as that account.

This isolation is enforced by the operating system itself, not by the wallet. According to the NIST Cybersecurity Framework, identity and access control—the principle that users should only be able to access resources they are authorized to use—is a foundational security practice. Applying that principle to a shared device means respecting the boundary between user accounts and ensuring that login credentials for one account do not grant access to another’s data.

One common mistake is to use a single account with a screen lock or password, then share the password or leave the device logged in for convenience. A screen lock only prevents casual access; anyone with the password can log in and see everything in that account’s home directory. A better practice is to ensure that each person logs out or locks their account when they step away, and that no one shares their login password or biometric with others.

Browser profile separation within a single operating-system account

In some households, a single operating-system account may be shared (for example, a parental account used for administrative tasks), yet multiple family members still need independent wallets. In this scenario, creating separate browser profiles within Chrome, Brave, or Edge can provide a layer of isolation, though it is weaker than operating-system separation. Each browser profile maintains its own extensions, cookies, browsing history, and stored data. A user can launch a browser with a specific profile using command-line flags such as --profile-directory="Profile 2" on Windows or by creating a separate managed user in Chrome’s settings.

The constraint is that browser-level isolation does not prevent another person who has access to the operating-system account from viewing the profile’s directory directly through the file manager, copying extension data, or reinstalling a wallet extension with access to the files. Browser profiles are a usability feature, not a cryptographic boundary. They reduce accidental cross-access but fail against anyone with filesystem access and sufficient knowledge.

Furthermore, if the shared operating-system account is compromised—for example, by malware or an unauthorized person who knows the password—the attacker can access all browser profiles without restriction. For this reason, browser profile separation should only be considered a complementary measure, used alongside proper operating-system account isolation for anyone holding significant balances.

Setting a strong wallet password and enabling authentication gates

Within the Rabby wallet extension itself, the first interaction is typically a password. This password encrypts the wallet’s recovery phrase and private keys at rest within the browser extension storage. When a user imports a recovery phrase or creates a new wallet, Rabby requires a password during initialization. This password is separate from the operating-system login and the browser’s own password manager.

The password should be sufficiently complex and unique—at least 12 characters, combining uppercase, lowercase, digits, and symbols. A weak or shared password creates a second weakness: even if the operating-system and browser separation is perfect, anyone who can open the extension and knows the password can sign transactions, view the recovery phrase, or export private keys. A family member might casually guess a password based on birthdays, pet names, or shared family phrases.

Some versions of Rabby or other wallets offer additional authentication options such as biometric unlock (fingerprint or face recognition on mobile). On desktop browsers, this is less common, but if available, it should be enabled. The limitation is that biometric systems on computers are often less secure than on phones; a keyboard with a fingerprint reader can be spoofed more easily than a dedicated mobile device. Password strength therefore remains the primary lock.

A critical practice is to never allow the browser to save or auto-fill the wallet password. The browser’s password manager stores passwords with lower entropy than the operating system’s credential vault and can sometimes be extracted or bypassed. Instead, users should type the password each time they unlock the wallet. This creates a minor friction cost but eliminates the risk that someone who briefly accesses the device could use the browser’s autofill to sign into the wallet without knowing the password.

Managing recovery phrases on a shared device

The recovery phrase—the 12- or 24-word seed—is the master secret that can unlock any wallet derived from it. Loss or exposure of the recovery phrase is irreversible. On a shared device, the recovery phrase must be treated with exceptional care because it is, in principle, permanent and cannot be rotated like a password.

The Rabby wallet extension, like most self-custody wallets, displays the recovery phrase once during wallet creation and provides a way to view it later (usually behind password and confirmation dialogs). If a family member with access to the device obtains the recovery phrase, they can import it into their own wallet or a different device and gain complete control of all funds associated with that wallet. This risk cannot be mitigated purely through software; it depends on physical and behavioral controls.

The safest practice is to generate the recovery phrase on a device that is not shared, or at least to generate it in isolation (for example, when the shared device is being used only by one person, in a private setting). The phrase should be written down on paper and stored in a physically secure location—a safe, safety deposit box, or another locked container that other household members cannot access. The paper should never be stored on or near the shared computer, photographed, or typed into a cloud document, email, or messaging application.

If a recovery phrase must be stored on the shared computer, it should be encrypted with a password that is completely different from the wallet password and kept in an encrypted document or archive (such as a 7-Zip file with AES-256 encryption). The encryption password should be memorized and not written down. This creates a two-step barrier: knowing the Rabby wallet password does not grant access to the recovery phrase, and vice versa. However, this is only a delay tactic; a determined attacker with full access to the computer could potentially recover the original file through forensic techniques. For genuine security, the recovery phrase should not be stored digitally on a shared device at all.

Using the pre-transaction risk scanning feature to prevent unauthorized approval

One advantage of the Rabby wallet extension across its various deployments is the pre-transaction risk scanning system. When a user attempts to sign a transaction to interact with a dApp or send funds, the extension analyzes the transaction and displays warnings if it detects suspicious patterns—such as approving an unknown contract for unlimited token transfers, sending to a newly created address, or interacting with a known malicious contract.

On a shared device, this feature can serve as a secondary safeguard against a less sophisticated attacker or a curious family member. If someone gains access to the unlocked wallet and attempts to drain funds, the risk scanner will flag unusual transactions and ask for confirmation. This does not prevent the attack entirely (because the attacker can dismiss the warning if they see it), but it creates a visible checkpoint that reduces the likelihood of accidental or impulsive theft.

The official rabby wallet extension is open-source, with code published on GitHub, which means that its risk-detection logic can be reviewed by security researchers and the community. This transparency helps ensure that the feature is implemented correctly and not bypassing its own alerts through hidden logic. However, a risk scanner cannot prevent a determined attacker who understands what they are approving; it is a usability feature, not a cryptographic guarantee.

Device-level security: password managers, biometrics, and physical access

The operating-system user account isolation described above assumes that the account’s login is protected by a strong password or biometric. If the password is left on a sticky note, used for multiple accounts, or shared among family members, the isolation collapses. According to the Internet Society, authentication practices that resist casual guessing and social engineering are essential for personal information security.

A password manager such as Bitwarden, 1Password, or KeePass should be used to generate and store unique, high-entropy passwords for the operating-system account. The password manager itself should be protected by a strong master password or passphrase. If the device supports it, enable Windows Hello (on Windows) or Touch ID/Face ID (on macOS) for fast, biometric unlock without requiring the operating-system password to be typed repeatedly. Biometrics are less secure than passwords for critical systems, but they are more secure than passwords that are written down or shared.

Physical security is often overlooked but is critical on a shared device. If the computer is left unattended and unlocked, anyone in the household can access the wallet. Lock the device whenever stepping away, even briefly. On laptops, enable automatic sleep or lock after a period of inactivity—typically 5 to 15 minutes—to prevent someone from using an unattended machine.

Regulatory context and custody responsibility

A self-custody wallet like Rabby places complete responsibility for the security of private keys and recovery phrases on the user. Unlike a centralized exchange or custodial service, there is no corporate recovery or insurance if keys are lost or stolen. This responsibility becomes more complex in a household where multiple people have access to the same device.

Under FCA guidance and similar regulatory frameworks in other jurisdictions, individuals holding cryptocurrency assets are responsible for understanding the custody model and the risks associated with their chosen storage method. The FCA has emphasized that users should be aware of whether they or a third party controls the private keys and should understand the implications of self-custody, including the risk of permanent loss.

In a family context, this means that each person holding cryptocurrency through a self-custody wallet should independently understand the security practices and should not rely on another family member to secure their funds. If a teenager or less technologically experienced household member is using a wallet on a shared device, the more technically knowledgeable members should explain the security model and help establish proper isolation practices, but each person should ultimately be responsible for their own recovery phrase and password.

The European Commission’s DLT Regulation and similar rules in other jurisdictions are beginning to impose requirements on wallet providers and custodians regarding disclosure and user protection. While these regulations primarily focus on centralized services, they reflect a broader principle: users should have clear information about custody and security. A household practicing safe shared-device use should ensure that everyone involved understands what custody means and what could go wrong.

Testing isolation and creating a recovery plan

Before storing significant amounts of cryptocurrency on a shared device, the isolation setup should be tested. One person should create a test wallet on their user account, fund it with a small amount, and then attempt to access that wallet from another user’s account. If the wallet is not visible or accessible, isolation is working. If it is visible or can be unlocked without the correct password, the configuration needs to be corrected.

Each person using the wallet should also create a written recovery plan that addresses two scenarios: first, what happens if the shared device is stolen or malfunction, and second, what happens if they forget their wallet password. For the first scenario, the recovery phrase should be retrievable from its secure offline location and testable on a different device or phone. For the second scenario, a lost password is unrecoverable (because the password protects the encrypted storage of the recovery phrase), so it is essential that each person knows where their recovery phrase is stored and can retrieve it.

Testing recovery procedures is often overlooked but is critical. A person should practice importing their recovery phrase into a mobile wallet (such as a mobile version of Rabby, if available) or a different wallet application on a separate device, to ensure that the recovery phrase is correct and that they can execute the process under stress. This test should be done in private, on a device that is not shared, to avoid exposing the recovery phrase to other household members.