Nobody steals a one-time code by guessing it. Six digits that expire in a few minutes are hard to brute-force and most services lock the attempt after a handful of tries. Codes are taken in four other ways: the attacker persuades you to hand the code over in real time, the attacker takes control of the channel the code arrives on, the attacker sits in the middle of your login and passes the code straight through to the real site, or the attacker already has the device or mailbox where the code appears. Every real-world OTP theft is a variation on one of those four, and each has a different defence.
That matters because the usual advice — "turn on two-factor authentication" — treats all second factors as equivalent. They are not. Three of the four attacks below work perfectly well against an account that has 2FA switched on, and knowing which attack a given method actually stops is the difference between feeling protected and being protected.
A code is only as strong as the channel it travels on
A one-time code is a shared secret with a short life. The service generates it, sends it somewhere it believes only you can read, and accepts it back as proof you are you. The cryptography is not the weak part — the delivery is. The moment a code leaves the server it travels over a phone network or a mail server and arrives on a screen other people can sometimes see, in an account other people can sometimes open.
So the honest way to think about any code-based login is to ask who else could read the place it lands, and who could convince you to read it to them. If you want the mechanics of how the code is generated and checked in the first place, we covered that separately in how OTP verification works. This article is about the ways it goes wrong.
The four ways a code changes hands
1. The real-time phishing page that passes your code along
This is the one most people have never heard of and the one most likely to catch a careful person. Older phishing pages were static copies: you typed your password into a fake form, the attacker collected it later, and a second factor stopped them from using it. Modern phishing kits are not copies. They are proxies. The fake page sits between you and the genuine site and forwards everything in both directions as you type.
The experience from your side is indistinguishable from a real login, because it is a real login — just one being typed through someone else's server. You enter your username and password, and they are forwarded. The genuine service sends you a genuine code. You enter the code, it is forwarded, and the service accepts it. You land on your real account page. Nothing failed, nothing looked odd, and the attacker now holds the session cookie that the service issued at the end of that login, which lets them stay signed in without ever needing another code.
Note what did not help: the code was legitimate, it arrived at the moment you expected it, and the page behaved correctly. The only reliable tell is the address bar, which is why the checks that catch a phishing email — reading the domain right to left before the first slash, and refusing to log in from a link at all — remain the highest-value habit in email security.
2. The OTP bot that calls you before the code arrives
A whole category of services exists to automate the social-engineering half of this. The attacker, who already has your password from a breach dump, triggers a login and then places an automated call. The voice introduces itself as your bank's fraud team, says a suspicious transaction has been detected, and explains that it will now send a verification code to confirm your identity so the charge can be blocked. The code you receive is real and was triggered seconds earlier by the attacker. You read it out to stop a fraud that is not happening, and the login completes.
The script works because it inverts the timing. Instead of asking for a code out of nowhere, it gives you a reason to expect one, and frames reading it aloud as the protective action. The defence is a single rule with no exceptions: a code is something you type into a page you navigated to yourself. No bank, platform or support desk ever needs you to say one, read one, or forward one. If someone on a call wants a number you just received, the call is the attack.
3. The SIM swap that moves your number
If the code arrives by SMS, whoever controls the phone number receives it. A SIM swap is the process of convincing a mobile operator that you are the account holder and that your number should be moved to a new SIM. The attacker supplies details harvested from breaches and social media, the number ports, and your phone quietly loses service while their phone starts receiving your messages.
SIM swapping takes more effort than the first two attacks and is usually aimed at accounts worth real money. It is also the attack an authenticator app genuinely solves, because a code generated on your device never touches the phone network. Most carriers offer a port-out PIN or transfer lock; setting one is the only part of this under your control.
4. Access to the mailbox or the device itself
The least exotic route is the one people secure last. If the code goes to an email address, anyone who can open that mailbox can read it — and the mailbox is often protected by a password that has appeared in a breach, with no second factor of its own. An email address used for password resets is effectively a master key to every account that resets through it, which is why protecting the mailbox itself matters more than protecting any individual account downstream of it.
On the device side, lock-screen previews show the full text of most verification messages without unlocking anything, so a phone left on a desk is a readable code. A shared computer with a logged-in webmail session is the same problem in a different shape.
Why the method you choose decides which attacks you survive
Lining the four attacks up against the common second factors makes the gaps obvious.
- SMS codes fail against all four. They are relayable, they are the target of OTP bots, they are the thing a SIM swap steals, and they appear on lock screens.
- Email codes fail against relay phishing, OTP-bot calls and mailbox compromise, but are immune to SIM swaps. They are only as strong as the mailbox they land in.
- Authenticator app codes remove the channel entirely, so SIM swaps and carrier interception stop working. They can still be relayed through a proxy page or read out over the phone, because the code is still a number you type.
- Push approvals with number matching resist being read aloud, since there is nothing to dictate, and they make blind approval harder. A proxy page can still prompt a legitimate push that you approve.
- Passkeys and hardware security keys are the only option that defeats the relay, because the credential is cryptographically bound to the real site's domain. Presented with a lookalike domain, the key simply does not produce a signature. There is no code to intercept, repeat or dictate.
What to do if you think a code was used
Speed matters more than diagnosis. Change the password on the account, then find the "sign out of all devices" or active-sessions control and use it — because the thing an attacker keeps after a relayed login is a session, and a password change alone does not always kill it. Check the account's recovery email, phone number and any forwarding or filter rules, since those are what an attacker changes first to keep access after you lock them out. If the account was a mailbox, assume everything that resets through it is exposed.
Where throwaway addresses fit, and where they do not
Everything above argues for keeping the number of places a code can land small and well-defended. A shopping signup that only ever sends a confirmation link does not belong in the same mailbox as your bank, because every extra service holding that address is another breach that can expose it. A temporary inbox is a reasonable home for those one-off confirmations, precisely because it holds nothing worth stealing and disappears.
The inverse is just as important. Any account you would be upset to lose — anything with money, identity or years of history behind it — needs an address you will still control in a year, protected by its own strong second factor. A disposable inbox is the wrong place for a code that unlocks something you cannot afford to lose, and no amount of convenience makes that trade a good one.