Where Should You Type a Wallet Recovery Phrase?
A recovery phrase belongs in the wallet own restore flow, not a support chat or a borrowed VM. Trace where the secret is entered and who can watch.
Wallet recovery looks like a text-entry task and is actually a key-custody task. The phrase you type is not a password checked by a server; it is the input to a derivation function that rebuilds the same private keys the wallet had before it was lost. Anything that can read the keystrokes, the clipboard or the process memory at that moment can rebuild them too. Preparation therefore means deciding where the secret is allowed to exist, before it exists.
Trace the phrase from the medium to the derived key
A BIP-39 style mnemonic is normalised, stretched with PBKDF2-HMAC-SHA512 using an optional passphrase as salt, and turned into a seed from which the wallet derives keys. Two consequences follow directly. First, the phrase is durable authority rather than a session credential, so there is no server-side reset if it escapes. Second, the optional passphrase participates in the derivation, which is why a restore that seems to produce an empty wallet usually means the wrong passphrase was entered rather than a wrong phrase.
Every step after normalisation happens inside the process you typed into. That is the part most recovery guides skip: the exposure surface is the input path and the memory of that process, not the network between you and a website.
Which process is legitimate depends on the wallet. A hardware device has its own on-device recovery interface; a software wallet has a documented restore screen in a verified build. Neither is a support chat, and neither is a page that offers to check a phrase for you.
A guest system inherits its host's trust
A virtual machine feels like a separate computer and is not an independent trust boundary. NIST's full-virtualisation guidance describes the dependency directly: the security of the guest depends on the host and the hypervisor beneath it, and shared resources such as clipboard or folder integration widen the channel between them. Installing a guest on a machine you already suspect does not create a fresh input path.
| Control | What it addresses | What it leaves exposed |
|---|---|---|
| Verified wallet build | Running the code the publisher actually signed | Everything the running process can read once it starts |
| Live-boot environment, no persistent disk | Secrets left in swap, caches or a saved session | The firmware, the keyboard and the display path |
| Full-disk encryption on the host | Recovery material at rest after shutdown | The same material while the machine is unlocked |
| Tunnel to a trusted exit | Who can observe traffic in transit | Local processes, screen capture and input hooks |
Practical leaks follow the same line. A shared clipboard carries whatever you copied. Snapshots and suspended-state files can capture memory containing the phrase. Guest additions with host filesystem access give the guest a view of host paths and the host a view of guest paths. None of these are exotic attacks; they are features that make the VM convenient.
The honest conclusion is narrower than "a VM is unsafe". A VM can be the right container for the work when the host is the machine you trust and you have removed the sharing features. It cannot rescue a host you do not trust.
What an encrypted tunnel actually covers
A VPN protects packets between two endpoints. It has no opinion about who is reading the screen at either end, and it does not stop a local process from observing what you type into a window. So a tunnel is relevant when the concern is the path, and irrelevant when the concern is the host.
This distinction matters because the two get sold together. "Encrypted connection" describes transit; "trusted device" describes the endpoint. A recovery procedure needs both answered separately, and only one of them can be answered by a network service.
Verifying what you downloaded belongs to the same family of endpoint questions. A hash check and a signature check establish that the archive matches what the publisher released; they say nothing about the machine that will run it.
sha256sum -c SHA256SUMS.txt
gpg --verify SHA256SUMS.txt.sig SHA256SUMS.txtPrepare the environment before the material appears
Order matters more than tooling. Decide the host, remove sharing features, disconnect what does not need to be connected, and only then take the recovery record out of its storage. Doing it in the other order means the secret is already in memory while you are still deciding where it should go.
Then keep the secret in the flow the wallet maker documents. Enter it in the wallet's own restore interface, on the network the wallet expects, and approve only operations you can verify on the trusted display the wallet provides. A familiar desktop dialog is not proof that the device will authorise what the dialog claims.
If you suspect exposure, stop entering material on that system and move to an environment you can independently trust. Closing the VM, changing a VPN password or reinstalling the wallet application does not rotate the wallet's authority; only moving the assets to a new wallet with newly generated keys does. Keep the raw phrase out of any support conversation while you obtain the wallet-specific steps, because no legitimate support process needs it. That single rule prevents more losses than any hardening checklist.