Rabby Wallet on Public WiFi: Security Risks and Protective Measures When Trading on Open Networks

A trader sitting in a coffee shop with their laptop needs to respond quickly to a market movement. Their Rabby Wallet browser extension is installed, they are logged in, and the opportunity appears to require immediate action. The WiFi network broadcasts an open SSID with no password. Before they execute the transaction, they may not realize that an attacker on the same network could be positioned to intercept communications, modify transaction data, or redirect confirmations meant for hardware wallets. The convenience of working from anywhere must be weighed against the specific vulnerabilities that open networks introduce to a hot wallet environment.

Public networks create an asymmetric threat. The attacker does not need to compromise the user’s device directly. They need only intercept, observe, or modify the traffic between the device and the services Rabby connects to. Browser extensions are particularly exposed because they communicate with multiple external services—blockchain RPCs, market data providers, confirmation endpoints, and hardware wallet bridges. A single unencrypted or improperly validated connection can become the entry point for transaction interception or credential exposure. The risk is not theoretical; it is a documented class of attack against cryptocurrency users working on untrusted networks.

How public networks compromise browser extension security

A browser extension like Rabby Wallet depends on several types of network communication. The extension itself runs on the user’s device, but it must contact blockchain nodes to broadcast transactions, retrieve account balances, and validate transaction details. It may also communicate with hardware wallet services, WalletConnect endpoints, and dapp connectors. Each of these connections is a potential interception point when the underlying network is untrusted.

The technical weakness starts with HTTP versus HTTPS. Modern browsers enforce HTTPS for most websites, but some older services, custom RPCs, or node connections may still accept HTTP. On an open WiFi network, an attacker using tools like ARP spoofing or DNS hijacking can position themselves as a man-in-the-middle. They see the plaintext request, observe the wallet attempting to connect to a particular RPC endpoint, and respond with a modified version. Instead of the legitimate blockchain node’s response, they send back data that makes a transaction appear to fail, or they modify the transaction details to change the destination address.

WalletConnect introduces a different surface. When Rabby connects to a dapp via WalletConnect, the connection is established through a relay service or a local bridge. An attacker on the same network could intercept the pairing code, redirect it to their own controlled relay, or observe the connection metadata. They may not be able to forge signatures if Rabby is using a hardware wallet connection, but they could inject false transaction prompts or observe which dapps the user is connecting to. This may seem harmless, but connection timing and dapp access patterns can reveal trading activity.

Hardware wallet integration, while generally safer than a fully hot wallet, still depends on communication channels. Ledger, Trezor, and other devices communicate with the browser via USB or Bluetooth on local connections, but the dapp itself may be served over an insecure network. The attacker could modify what the user sees on screen before the hardware wallet is asked to sign. If the user approves a transaction based on incorrect information displayed in the browser, the hardware wallet’s signature protects the blockchain from forgery, but it does not protect the user from sending funds to the wrong address. The security boundary is only as good as the information presented before the signature request.

IP address and metadata exposure are often overlooked. Even if all traffic is HTTPS, the attacker can still observe which services the device is contacting, how frequently, and the size of data being sent. This metadata can reveal that a user is trading, checking balances, or connecting to a specific dapp. Combined with timing information, it could allow an attacker to infer trading patterns or prepare for follow-up attacks. A user who checks a wallet balance and immediately executes a large trade may be engaged in a time-sensitive transaction; an attacker aware of this pattern could prepare a denial-of-service attack or attempt to monopolize liquidity.

The specific risks of signing transactions on untrusted networks

The most direct vulnerability is transaction interception or modification. A user composes a transaction in Rabby—selecting an asset, amount, and destination—and broadcasts it to the blockchain. On a secure network, the transaction bytes are encrypted in transit and verified by the recipient. On an open WiFi network, an attacker can position themselves between the user’s device and the RPC endpoint. They cannot forge the user’s signature if a hardware wallet is being used, but they can observe the transaction, delay it, or cause a retry loop that makes the user believe the network is congested when it is actually under attack.

More sophisticated attacks target the signing step itself. If Rabby is used without a hardware wallet—that is, with a seed phrase or private key stored locally—the attacker’s goal is different. They still cannot extract the key over the network if the browser extension has been properly implemented, but they can use timing attacks, examine cached data, or cause the device to send confirmation requests to attacker-controlled servers. The user might see a legitimate-looking confirmation prompt that is actually being relayed through the attacker’s machine. They approve what looks like a small transfer, but the attacker modifies the data to request a larger transaction or a different destination.

Phishing through false service replies is a practical concern. When Rabby tries to connect to a hardware wallet via a bridge service or when it communicates with a mobile wallet through WalletConnect, the user expects certain behavior. An attacker can intercept the request and return a fake response that simulates the expected behavior while actually capturing session tokens or pairing information. A user might see a familiar confirmation screen from their Ledger or Trezor, approve a transaction, and not realize until much later that the interaction never reached the actual device.

Supply chain and middleware attacks also operate in this space. If a user is relying on a publicly available RPC endpoint that is not pinned in Rabby’s configuration, they are trusting both the endpoint provider and the network infrastructure between their device and that endpoint. A compromised RPC endpoint can send false balance information, confirm fake transactions, or return malicious contract ABIs. When combined with the ability to intercept network traffic, this becomes a complete attack surface. The user sees a balance, confirms a transaction, and believes everything is correct, while the attacker has either stolen the transaction data or prepared a follow-up attack based on the observed activity.

Why hardware wallet connections are not a complete solution on public networks

Hardware wallets like Ledger and Trezor provide a significant security improvement because private keys never leave the device. A signature cannot be forged by a man-in-the-middle attacker because the actual cryptographic operation happens on the hardware device, not on the compromised network. However, hardware wallets still depend on a secure channel between the user’s computer and the hardware device itself, and between the computer and the services that facilitate signing requests.

The attack surface shifts rather than shrinks. An attacker cannot forge a signature, but they can still modify what the user sees before they request a signature. If Rabby displays an incorrect destination address because the network connection has been intercepted, the hardware wallet will happily sign a transaction to that address. The private key remains secure, but the user’s funds are sent to the attacker. This is why the human verification step—the moment when the user reads the screen and confirms what they are approving—is critical on untrusted networks. A hardware wallet signs what it is told to sign; it does not validate whether the destination is correct.

WalletConnect adds another layer. When Rabby uses WalletConnect to connect to a mobile wallet like MetaMask Mobile or Trust Wallet, the bridge or relay service coordinates the signing request. An attacker on the same network could intercept the pairing code, observe the relay’s responses, or cause the mobile device to receive a false signing request. The hardware wallet eventually protects against forged signatures, but only if the signing request was legitimate in the first place. An attacker who can inject false requests or modify legitimate ones before they reach the mobile wallet has created a weakness that the hardware cannot solve.

The defensive implication is that hardware wallet security on public networks requires that the user can verify transaction details through an independent channel. This is impractical for frequent trading. Reading every transaction detail carefully while sitting in a coffee shop, checking that the destination address matches something written on paper, and confirming the amount matches what they intended is better than nothing, but it is a weak defense against a determined attacker who has had time to prepare. The user’s attention is finite, and an attacker can exploit fatigue or hurry.

Network-level attacks: DNS hijacking, ARP spoofing, and SSL stripping

Three classic network attacks are particularly relevant on public WiFi. DNS hijacking redirects requests for legitimate services to attacker-controlled servers. When a user’s device looks up the IP address for a blockchain RPC endpoint or a hardware wallet bridge, the attacker intercepts the query and responds with a different IP. The user’s browser or wallet extension connects to the fake server, which looks legitimate because it uses the correct domain name in the URL. The attacker can then relay some requests to the real server while capturing transaction details or injecting false responses.

ARP spoofing allows an attacker on the same local network to intercept all traffic by claiming to be the WiFi gateway. Instead of traffic flowing directly from the user’s device to the internet, it flows through the attacker’s device first. This is a complete man-in-the-middle position. Even if HTTPS is used, the attacker can observe which domains are being accessed, how much data is being sent, and the timing of requests. They can also inject delays, cause retries, or perform SSL stripping if a user accidentally follows an insecure link.

SSL stripping is an older attack, but it remains effective if a user has ever accessed a service over HTTP before. The attacker intercepts HTTPS requests, communicates with the legitimate server using HTTPS, but serves a plaintext HTTP version to the user. If the user does not notice that the padlock icon is missing or the URL changed from HTTPS to HTTP, their data travels unencrypted through the attacker’s system. For a wallet extension, this could mean that wallet data, transaction details, or authentication tokens are captured as plaintext.

The practical consequence is that a user on public WiFi cannot assume that any connection is secure simply because it looks normal. The browser may display HTTPS in the address bar, but it could be lying. The domain name in the address bar could match the legitimate service, but the actual server could be controlled by an attacker. This is why security experts recommend avoiding sensitive operations on public networks altogether, but that is often impractical. A user who must trade or manage assets on public WiFi should understand that every connection is suspect until verified through an independent channel.

Practical protective measures without requiring a VPN

A Virtual Private Network (VPN) is the most direct mitigation, encrypting all traffic and routing it through a trusted server. However, VPN recommendations come with caveats. A VPN provider has visibility into traffic volumes, connection timing, and potentially the destinations being accessed if the VPN does not log. An attacker on public WiFi cannot intercept traffic, but the VPN provider theoretically could. A user must trust the VPN provider more than the local network, which is often a reasonable trade-off. The important point is to use a reputable VPN from a provider with a clear no-logging policy and to verify that the VPN is active before connecting Rabby to public networks.

Without a VPN, several other measures reduce (though do not eliminate) risk. First, use your own mobile hotspot instead of public WiFi whenever possible. A hotspot is still a wireless connection, but it is controlled by you and encrypted with your own password. An attacker would need to gain access to your device or crack the WiFi encryption, which is much harder than monitoring an open network.

Second, disconnect from the network when not actively trading. If Rabby is connected to public WiFi but the user is reading a news article or checking a hardware wallet status, an attacker has time to set up interception. Minimize the window of exposure by staying connected only during the actual transaction process, then switching to airplane mode or disconnecting.

Third, use hardware wallet connections and WalletConnect when available rather than signing with a locally stored seed phrase or private key. The hardware wallet or mobile wallet connection adds an additional security boundary. Even if the browser connection is compromised, the signing step still happens on a device that the user controls.

Fourth, use the secure decentralized wallet features that Rabby provides. The watch-only address functionality allows you to monitor balances without signing transactions on public networks. If you are simply checking a balance or reviewing transaction history, use watch-only mode. The private key or signing capability should remain offline or on a secure network until an actual transaction is needed.

Fifth, verify transaction details independently when possible. If you are about to send funds to an address, confirm that address by sending it to yourself from a trusted channel first, or by entering it manually from a written record rather than copying and pasting. This prevents an attacker from modifying the destination in transit. For large transactions, send a small test amount first and wait for confirmation before sending the full amount.

Institutional and advanced configurations for professional traders

If Rabby is being used for significant trading activity, institutional solutions offer better separation of concerns. Safe provides multi-signature controls, meaning transactions require approval from multiple signers before execution. An attacker who compromises a single network connection cannot authorize a transaction alone. Cobo, Fireblocks, and MPCVault offer even more sophisticated key management, distributing signing authority across multiple parties or devices.

For professional traders, the approach should be to never sign transactions from public networks, regardless of the wallet. Instead, create a read-only or watch-only instance of Rabby on the public network device to monitor positions and prices. Use a separate device, connected only to private networks, to hold keys and approve transactions. WalletConnect can facilitate this: the trading device displays transaction details and requests a signature, while the signing device—connected via a mobile hotspot, Bluetooth, or a local network at home—approves the signing request without ever connecting to public WiFi.

This approach requires discipline and a bit of extra setup, but it fundamentally reduces the attack surface. An attacker who compromises the public WiFi network where you are monitoring prices cannot access the keys or approve transactions. An attacker who compromises your home network does not have visibility into the public network traffic. The two environments remain separated.

Contact management through Rabby’s address book also becomes relevant for high-value transfers. If you add frequently used destination addresses to your Rabby wallet as saved contacts, you reduce the need to copy and paste addresses in public settings. A saved contact cannot be modified by an attacker who compromises the network connection; they would need to compromise your device directly.

What to do if a transaction appears suspicious during execution

If you are trading on public WiFi and notice any unexpected behavior—a transaction that seems to hang, a confirmation request that appears twice, a balance that changed without your action, or a destination address that looks different from what you entered—stop immediately and disconnect from the network. Do not attempt to retry the transaction while still on the public network.

Check the blockchain directly using a block explorer. Search for your wallet address and verify what transactions have actually been confirmed. If a transaction you approved has been broadcast to the wrong address, you may be unable to recover it; the blockchain’s immutability works against you in this case. If the transaction never reached the blockchain, it is possible that it was intercepted but not executed. If you see a transaction that you never approved, your device may have been compromised more directly than a network attack.

After resolving the suspicious activity, do not reuse the same network or location for sensitive operations. If the attack was sophisticated, the attacker may still be positioned on that WiFi network. Move to a different location with a different network connection, then assess whether your device needs security scanning. If you were using a hardware wallet, the risk is lower because the signing happened on a secure device; if you were using a locally stored private key, consider moving those funds to a new wallet on a secure network as soon as possible.

Document what happened and report the incident to relevant services. If you used a specific RPC endpoint, contact that provider. If you used WalletConnect, the relay service may have logs. The goal is not necessarily to recover lost funds—the blockchain does not allow reversal—but to help identify whether a systematic attack is underway and to protect other users in similar situations.