Skip to main content

Wallet Security

The Extra Wallet is built around a split security model:

  • The wallet UI runs on one origin.
  • All sensitive operations (keys, mnemonics, signing, etc.) happen in a separate app called the Signer, running in an iframe on a different origin.
  • The two sides communicate only through a strict message channel, never by sharing direct access to storage or in-memory secrets.

This page gives a high-level overview of how it works.
👉 For more details, explore the Signer security model.

Security Model at a Glance​

1. Isolated Signer​

The signer is loaded in an <iframe> from a separate origin. It explicitly checks allowedOrigins during initialization to ensure it is only embedded by authorized applications.

Hard Isolation

Even if the wallet UI is compromised, it cannot access the signer’s IndexedDB or JavaScript memory.

2. Restricted Communication​

The wallet and signer communicate only via the browser’s MessageChannel.

  • The wallet uses a Proxy pattern to invoke methods on the signer.
  • The signer exposes three distinct services:
    • SafeView: Handles sensitive UI operations (e.g., password prompts, mnemonic display) and authentication.
    • SafeStorage: Handles storage operations (e.g., adding, removing, updating accounts, etc.).
    • SafeSigner: Handles the actual signing operations.
  • The wallet never touches raw private keys or decrypted mnemonics.

3. Local, Encrypted Secrets​

All sensitive data (private keys, mnemonics, etc.) live only on the signer side, inside IndexedDB in the user’s browser.
The wallet app only ever sees public data:

  • public addresses
  • public keys
  • non-sensitive metadata (labels, derivation paths, etc.)

4. Password-Protected Access​

On the signer side, all secrets are encrypted with a key derived from the user’s password.
Whenever an operation needs sensitive data (e.g. signing, deriving keys, etc.), the signer:

  1. Asks the user for their password in the signer iframe UI.
  2. Derives or reuses an in-memory key.
  3. Decrypts only what is needed to complete the operation.

5. Configurable Crypto Algorithms​

Users can choose which algorithm to use on the signer side:

  • Secure (recommended): argon2id (from @noble/hashes/argon2) → AES-GCM
    • Memory: 64MB
    • Iterations: 3
    • Parallelism: 1
    • Key Length: 32 bytes
  • Legacy / weaker: PBKDF2 → AES-GCM
    • Iterations: 1000
    • Hash: SHA-256
    • Key Length: 256 bits
tip

The secure option is memory-hard and designed to resist brute-force attacks on the password.

Why This Is Safer Than a Single-App Wallet​

Traditional browser wallets often:

  • keep keys in the same origin as the main UI,
  • expose decrypted secrets or password-derived keys to a large code surface,
  • or mix third-party dApp code with the wallet’s own logic.

In Extra Wallet:

  • Secrets never leave the signer origin.
  • The wallet UI has no direct access to:
    • IndexedDB with secrets,
    • the decryption key,
    • or any sensitive in-memory data.
  • Every sensitive UI (password prompts, seed displays, confirmation dialogs with private info) is rendered inside the signer iframe, not by the main wallet application.
info

This separation means that even if some bug or malicious code appears in the main wallet UI, the attacker still cannot read or export your keys; they can only request operations that the signer will validate, show to the user, and ask for a password when needed.

Where to Learn More​

For a deeper, implementation-level explanation (MessageChannel wiring, IndexedDB layout, encryption details, in-memory key handling), see:

👉 Signer security model

Developer Info​

  • Built and maintained by the Extra Wallet team.
  • Source: Extra Wallet