Two-factor authentication (2FA) is an extra step at login on top of the password. Exchange accounts commonly offer four kinds: SMS codes, codes from an authenticator app, hardware security keys and passkeys. They work in different ways and their weaknesses differ widely, so having 2FA turned on says little until you know which kind it is.
The four kinds of two-factor authentication
Login credentials generally fall into three categories: something you know (a password), something you have (a phone, a key) and something you are (a fingerprint, a face). 2FA usually adds something you have on top of the password.
SMS codes
At login the platform texts a code to your phone number and you type it into the page. Nothing has to be installed, so the barrier is the lowest of the four. It also has the most weaknesses, which the next section covers.
Authenticator app codes (TOTP)
Authenticator apps such as Google Authenticator and Microsoft Authenticator use the TOTP algorithm. During setup you scan a QR code, which stores a shared secret (often called the seed) in the app. From then on the app computes a string of digits from that secret and the current time, and you type it in at login. Under RFC 6238 the default is a new code every 30 seconds.
Compared with SMS, the seed sits on your device and the code never passes through the carrier. It is still a string of digits that you type into a web page by hand, and the problem that causes comes up later.
Hardware security keys (such as YubiKey)
A separate physical key. Taking Yubico's YubiKey 5 Series as the example, the interfaces Yubico lists are USB-A, USB-C, NFC and Lightning. At login you plug it in or hold it near the device, touch the key when the browser prompts you, and the login completes.
The difference from a code is that at no point do you type any digits. That is what blocks a phishing relay.
Passkeys
Passkeys use the same FIDO standards as hardware keys. The difference is that you do not need to buy a separate key, because the phone or computer itself acts as one. The FIDO Alliance's explanation divides them into two kinds: those synced across your devices, and those bound to a single device or hardware key.
Why SMS verification codes are not safe
SMS codes travel over the phone network, and where a code ends up depends on which SIM card your number is attached to at that moment. The attack aimed at this is the SIM swap: the attacker impersonates the account holder and gets the carrier to reissue or transfer your number to a SIM card they hold. Once that succeeds, your phone loses signal and every SMS code sent to the number goes to them.
There are public figures for these cases. In Public Service Announcement I-020822-PSA, published on February 8, 2022, the FBI's Internet Crime Complaint Center (IC3) wrote that from January 2018 to December 2020 it received 320 SIM swapping complaints with adjusted losses of approximately $12 million, and that in 2021 alone it received 1,611 complaints with adjusted losses of more than $68 million. One of the announcement's recommendations for individuals is to use stronger multi-factor authentication, such as biometrics, physical security tokens or standalone authentication applications.
Standards take the same position. NIST's digital identity guideline SP 800-63B classifies sending codes over the phone network (SMS or voice) as a restricted method and requires the verifier to consider risk indicators such as device swap, SIM change and number porting before sending a code.
The trouble with SMS codes is that they are out of your hands. However strong the password and however clean the device, an attacker who persuades the carrier receives your codes. A key link in this defense sits with the carrier, and none of the other three methods has that link.
So the way to handle SMS is to turn it off wherever you can and use an authenticator or a passkey instead. Where a platform requires you to keep a phone number or SMS verification, follow its official instructions and add the stronger method as well.
What authenticator codes stop and what they do not
The seed for authenticator codes is stored on your device and does not go through the carrier, so a SIM swap does nothing to it. That is where it beats SMS.
What it does not stop is a phishing relay. A code is a string of digits you read off and type into an input box. Suppose a phishing site looks identical to the real one and you type your code into it. The server behind the phishing site can pass the code on to the real site while it is still valid. The real site accepts it, and the one who gets logged in is the attacker.
No particular authenticator app is at fault here; every code that has to be typed in by hand behaves the same way. NIST's SP 800-63B is direct about it: authenticators that involve manual entry of an authenticator output, one-time passwords (OTP) included, are not considered phishing-resistant.
The other thing to watch is where the seed lives. With an authenticator that stores it only on the device, you have to export the seeds or re-enroll site by site before changing phones, and a lost phone means going through each platform's recovery process. An authenticator with cloud sync saves that step, but from then on the seeds are only as safe as that cloud account: if it is breached, the seeds go with it. Either kind works. Whichever you choose, look after the end it depends on.
Why a hardware security key stops phishing sites
A hardware key produces a signature instead of digits, and it signs only for the site it was registered with.
The standard behind this is the W3C's WebAuthn. At registration the key generates a public-private key pair for the site, hands the public key to the site and keeps the private key inside. The standard scopes every credential to one site identifier (the RP ID, which is a domain), so afterwards only pages belonging to that site can use it. The browser and the key enforce that restriction together, and it does not depend on how sharp your eyes are.
In a phishing scenario: you registered the key at example.com and are later led to a lookalike domain that repeats one of its letters. The browser sees a different domain, finds no example.com credential under it, and the signing step cannot proceed. The phishing site gets nothing it could pass on to the real site.
The second protection is the touch. WebAuthn calls it a test of user presence: someone has to physically touch the key before it signs. If the computer is under remote control, or malware requests a signature in the background, nobody touches the key and it does not sign.
The remaining risks are physical: the key is lost or taken, someone tricks you into plugging it in and touching it, or you buy a key that has been tampered with. Buying from the manufacturer's official channels avoids the last one. Carrying your main key with you and locking the backup away deals with the first two.
Besides FIDO2 and U2F, the functions Yubico lists for the YubiKey 5 Series include smart card, OTP and OpenPGP. For prices, go by Yubico's own website.
What a passkey is and how to set one up
In one sentence: you sign in to a website with your device's screen lock (fingerprint, face or unlock passcode) in place of a password. By the FIDO Alliance's definition, a passkey is a FIDO cryptographic credential tied to your account on a website or app, designed with no shared secret and resistant to phishing.
The principle is the same as the hardware key in the previous section: a public-private key pair. Apple's page on passkey security spells it out: the device generates a separate key pair for each account, the server stores only the public key, and the private key is never handed to the server. So even if the site's database leaks, only public keys get out, and they cannot be used to sign in to your account. Refusing to sign when the domain does not match works the same way as with a hardware key.
How to set up a passkey
First make sure the device has a screen lock. On most platforms the option is in the account's security settings under the name Passkey. Taking a Google Account as the example, the steps on Google's help page are:
- Set up a screen lock on the device first (fingerprint, face or PIN all count). iPhone, iPad and Mac also need iCloud Keychain turned on.
- Open myaccount.google.com/signinoptions/passkeys and click Create a passkey.
- Unlock the device once when prompted, and the passkey is created.
To sign in on someone else's computer, or on a device that does not hold your passkey, you can hand off to your phone: on the sign-in page choose Try another way, then Use your passkey. A QR code appears on screen. Scan it with the phone that holds the passkey and unlock the phone. Google's instructions mention that this step needs Bluetooth turned on.
Three things to watch when using passkeys
A passkey is no stronger than your screen lock. It relies on the device unlock to confirm that it is you. If the screen lock is a simple 4-digit code, the passkey's protection is only as strong as those 4 digits.
For synced passkeys, security depends on the cloud account. Apple's explanation is that passkeys sync across your devices through iCloud Keychain, that the keychain is end-to-end encrypted with keys Apple does not hold either, and that an account using iCloud Keychain must have two-factor authentication turned on. In other words, look after the cloud account's own password and 2FA, or the passkeys synced through it will be in trouble along with the account.
Know what to do if a device is lost. Google's approach is to sign in to the account from another device that still works and delete the passkey that was on the lost device. If every device is lost and you cannot get into the cloud account either, the only route left is the platform's account recovery process, so keep your recovery email and the backup codes the platform gives you stored separately.
Not every platform supports passkeys, and those that do each have their own limits. Go by what the platform's security settings page and help center say at the time.
What each method stops, in one table
The conclusions of the sections above, put into one table:
| Method | SIM swap | Phishing relay | What you have to protect |
|---|---|---|---|
| SMS codes | Not stopped | Not stopped | The phone number, which is really in the carrier's hands |
| Authenticator codes | Stopped | Not stopped | The device holding the seeds, or the cloud account that syncs them |
| Hardware security key | Stopped | Stopped | The physical key, plus a backup key |
| Passkey | Stopped | Stopped | The device's screen lock, and the cloud account used for syncing |
Stopped, in this table, means the attack technique itself does not work against that method. It does not mean the account is safe from then on: as long as SMS remains on the account as a backup verification or recovery method, the SIM-swap route is still open.
One phishing site, two outcomes: authenticator codes and a security key
Run the mechanics above through a single scenario. Suppose you are led to a reverse-proxy phishing site: the domain looks familiar, the address bar still shows a padlock, and whatever you type on the page is forwarded unchanged to the real site.
You use authenticator codes: you type your email, your password and the digits from the authenticator, and the phishing site forwards all three to the real site while the code is still valid. The real site accepts them and the attacker gets a valid login session. If a withdrawal later asks for another code, the phishing site can keep asking you and keep forwarding.
You use a hardware key or a passkey: after you type the email and password, the browser looks for a credential under this domain. Your credential is registered under the real site's domain and there is none under the phishing domain, so the signing step cannot proceed. The phishing site gets nothing it could forward to the real site.
The difference does not come down to how careful you are. A code can be taken as soon as it is typed into a phishing page, while hardware keys and passkeys are built so that they do not sign for the wrong domain.
How to combine 2FA methods on an exchange account
Take it in three steps, from least effort to most.
Step one: replace SMS. If the account holds any money, move login and withdrawal verification from SMS to authenticator codes. No hardware has to be bought. Then look again: is SMS still listed on the account as a backup verification or recovery method? If it is, the SIM-swap route remains open. Turn it off wherever you can, and where the platform requires it, follow its official instructions.
Step two: add a phishing-resistant method. Authenticator codes do not stop a phishing relay. To close that gap, enroll a hardware key or a passkey. With hardware keys I suggest buying two and enrolling both on the account: one to carry day to day and one locked away at home. With only one, losing it means going through account recovery.
Step three: keep a way back. If you use passkeys, give the device's screen lock a longer passcode in place of 4 digits. Fingerprint and face unlock are shortcuts, and the passcode is what stands behind them, so make the passcode strong and leave it turned on. The cloud account that syncs your passkeys needs decent 2FA as well. Where the platform provides backup codes, copy them onto paper and put them away, and do not store them on an internet-connected device.
Which methods a platform supports, and whether you can enroll more than one key, is whatever its security settings page and help center say at the time. If you can pick only one, prefer a phishing-resistant hardware key or passkey.
When choosing, one question is enough: in the worst case, who holds the key to this lock? With SMS the carrier holds it. With authenticator codes it is on your device, but you may hand it to a phishing site yourself. With a hardware key it is the physical object you carry. With a passkey it is in your device and your cloud account. How to recognize the various phishing techniques is covered in the guide to crypto phishing scams.