Two-Factor Authentication for Crypto: Ranking Factors

Two-factor authentication is treated as a single feature that is either on or off. It is not. The factor types differ enormously in what they defend against, and choosing among them matters more than enabling something.

Ranking the Options

The column that separates the top from the rest is phishing resistance.

A code is a secret you type. If you can type it into the real site, you can type it into a convincing copy, and an attacker relaying it to the real site in real time is authenticated as you. Every code-based factor shares this weakness.

A hardware security key does not produce a code. It performs a cryptographic exchange that includes the identity of the site requesting it, and it will not respond correctly to a different site. A user fooled by a lookalike page still cannot hand over anything useful, because the key itself refuses.

That is the property worth paying for.

Where Two-Factor Does Nothing

Two-factor authentication protects accounts. A self-custodied wallet is not an account: there is no server, no login and no session to protect.

Its security rests on two different things. Where the key is stored, which is the subject of seed phrase storage and cold storage. And what you approve when signing, which is the subject of verify before signing and token approvals.

A wallet application that asks for a passcode is protecting access to the app on that device. That is useful against someone picking up the phone and worth having. It is not two-factor authentication in the sense this page uses.

Practical Setup

Start with the email account. Every other account’s recovery path runs through it, so the strongest factor available belongs there first. An exchange account protected by a hardware key behind an email account protected by SMS is protected by SMS.

Then exchange accounts and anything holding value. Use a hardware key where offered, an authenticator application otherwise.

Enrol a second key or save the backup codes at setup. Not later. The scenario where you need them is the scenario where you cannot access the account to create them.

Remove SMS as a factor and as a recovery option once something better is in place. Leaving it enabled alongside a stronger factor keeps the weakest path open, and attackers use the weakest path.

Backup and Recovery

The most common way people lose access to their own accounts is losing the authenticator device without having kept the backup codes.

Store codes somewhere separate from the device that generates them and separate from the account they protect. Printed and kept physically is unsophisticated and works. A password manager with its own strong second factor works. An email to yourself does not, because the email account is what the codes might be needed to recover.

For hardware keys, a second key enrolled at the same time and kept in a different place is the equivalent. Services that support keys almost always support enrolling more than one.

What About Passkeys

Passkeys use the same underlying cryptography as hardware keys and inherit the phishing resistance, with the credential stored on a device rather than on a separate token.

Where they are synced across devices through a platform account, the security of that platform account becomes part of the picture. Where they are bound to one device, losing the device is the recovery problem to plan for.

They are a clear improvement on codes, and the trade-off against a discrete hardware key is about where the credential lives rather than about the strength of the mechanism.

What People Get Wrong About This

The first mistake is treating all second factors as equivalent. The gap between a hardware key and an SMS code is larger than the gap between SMS and nothing.

The second is securing exchange accounts while leaving the email account weaker. The recovery path is the real perimeter.

A third is leaving SMS enabled as a fallback after adding something stronger. It remains available to an attacker.

A fourth is not saving backup codes, which turns a lost phone into a lost account.

A fifth is expecting two-factor authentication to protect a self-custodied wallet. Different threat, different defence.

And the last is assuming a strong password removes the need for a second factor. Credential reuse and leaked databases mean passwords fail routinely, which is the reason second factors exist.

Where It Fits

Two-factor authentication defends the custodial half of the picture. It does nothing for the self-custody half, which is defended by key storage and by reading what you sign. Most people hold both, and the two halves need entirely different habits.