
Paperis Articles
The Limits of Two-Step Verification — Which Visitors Can Still Open the Second Door?
How far a second check reaches: nearly shut against stolen passwords, yet still open to real-time relays, hijacked phone numbers, reflexive approvals and weak account recovery
Your field's papers, as audio
Pick your fields and journals — Paperis summarizes the key papers and turns them into audio. Listen on your commute.
Start Paperis free →The Limits of Two-Step Verification — Which Visitors Can Still Open the Second Door?
「Would You Like to Approve This Login?」 Pop-up on Your Phone
Monday morning, when you log into your company email, a notification pops up on your phone. 「Would You Like to Approve This Login?」 When you tap approve, your mailbox opens. At lunchtime, after entering your password in your banking app, you enter a six-digit number sent via text message one more time.
Company and bank notices usually say the same thing. They say that even if your password leaks, a second check stops someone else from getting in. This claim sounds plausible. A password consists of text in your head, so it can leak from somewhere without your knowledge. Your phone is in your pocket. Someone who gets their hands on your password does not hold your phone, so they stop at the second door.
The news features the other side of the story as well. It tells of someone who tricked a telecom carrier to transfer someone else's phone number to their own SIM card, received the text-message numbers instead, and looted accounts. Since then, people often say 「SMS authentication is useless.」
The two statements point in opposite directions. One says turning on the second check settles it, while the other says one of the most common methods stops nothing. This article follows the evidence to separate the ranges where each statement is right and where it is wrong. The question is narrower than whether to turn it on or off. It asks which method stops which attack, and in front of which attacks the second door opens as well.
Papers uploaded to open servers such as arXiv and Zenodo are marked as 「open server version」.
A Person Holding Only a Stolen Password Stops Almost Completely at the Second Door
From March 2016 for one year, 1,900,000,000 IDs and passwords were traded on dark web boards. When matched against Google accounts, 7 to 25 percent of the leaked passwords matched the victims' Google account passwords (DOI: 10.1145/3133956.3134067). This means that a password that leaked from another site was also the correct password for the email account. This attack of logging into a victim's other accounts with passwords stolen from one place is credential stuffing ("Passwords and Passkeys — How Do You Prove You Are You?").
Placing a second door in front of this attack is multi-factor authentication, a method that requires two or more different types of evidence among what you know, what you have, and body characteristics together. There are results measuring that effect with large data. This is a 2023 study (public server version) where Microsoft researchers analyzed users showing suspicious activity in their corporate account service (Azure Active Directory). Accounts with multi-factor authentication turned on remained secure more than 99.99 percent of the time during the survey period (arXiv:2305.00945).
In the same study, multi-factor authentication reduced the risk of accounts being breached overall by 99.22 percent, and by 98.56 percent even in accounts known to have leaked passwords (arXiv:2305.00945). This means that even if a password is already in someone else's hands, the presence of a second door leaves less than 2 percent of the original intrusion risk. These figures are results measured by the parties themselves in their own service and are not independent measurements, and the targets were accounts that already showed suspicious activity. Based on these results, the authors strongly recommend turning on multi-factor authentication by default for commercial accounts.
The answer to the second conventional wisdom is also in the same data. Dedicated authenticator apps were better than text message authentication, but both methods significantly increased security compared to not using multi-factor authentication (arXiv:2305.00945). The saying "Text message authentication is useless" is not true, at least in the situation measured by this data, which is the situation where someone tries to log into my account.
In front of an attacker holding only a password, a second confirmation including text messages almost closes the door.
Asking Not Every Time, But Only When Strange
Adding risk signals such as the place and device a user usually accesses to login verification helps reduce the risk of accounts being hijacked with leaked passwords. This is the result shown by the Google case analysis earlier (DOI: 10.1145/3133956.3134067).
Risk-based authentication is turning this idea into a method. Risk-based authentication is a method that watches features like where you connected or what device you used when logging in, and asks for one more check only when it is very different from usual values. Security agencies in many countries recommend this method, and users find it easier to use and just as secure as two-factor authentication at the same level. Yet, very few online services use this method, and one of the reasons is a lack of proven public data on configuration and implementation (DOI: 10.1145/3546069).
To fill that gap, a research team collected login records of 3,300,000 users for over a year from a large real-world online service. If you configure settings with this data, users could benefit from this method in just a few logins (DOI: 10.1145/3546069). This means people logging in as usual are generally checked only once, and only unfamiliar connections are checked one more time.
Why it matters how far you ask is shown by a field study at a university. While a large public university gradually mandated two-factor authentication for faculty and students, researchers conducted multiple surveys and reviewed months of authentication logs. When it was made mandatory only for some systems handling sensitive information, there was no meaningful change in user experience and acceptance. When it was forced every time someone logged into all resources at the university, both got worse (DOI: 10.1145/3313831.3376457). A study observing the rollout at Carnegie Mellon University found that people who used two-factor authentication found it quite easy to use despite finding it annoying, and believed their accounts became safer (DOI: 10.1145/3173574.3174030).
In this university's survey, the cost of the second check grew larger from how far you ask every time rather than whether you turn it on. We will return to this point later when looking at approval notifications.
Text Messages Go to the Person Holding the Number
A one-time code arriving by text message—meaning a string of numbers that is used once or expires quickly—goes to whoever receives text messages at that phone number. A SIM-swapping attack is an attack where an attacker manipulates a mobile carrier to transfer a victim's phone number to a SIM card held by the attacker. Once the number is handed over, the attacker can change the passwords tied to that number, gaining entry into bank and social media accounts (DOI: 10.1109/ic3iot60841.2024.10550217).
There is also a path on the telecommunications network side. The fact that text messages can be intercepted using legacy signaling systems exchanged between carriers has been known since 2014. A 2017 study shows that text messages can be intercepted regardless of the device or operating system even within the connection architecture of the new LTE network, and demonstrates the real-world impact on services from companies like Google, Microsoft, and Twitter (DOI: 10.1109/icc.2017.7997246). Such interception assumes an attacker who can access the connection network between carriers. In front of such an attacker, no matter how careful the user is, the pathway through which text messages travel itself leaks.
The weakness of text messages lies in the pathway called the phone number. An authenticator app that generates codes inside the mobile phone does not use that pathway. In the previous Microsoft material as well, dedicated authenticator apps were better than text messages, and the abstract does not separately state the cause of that difference (arXiv:2305.00945). However, the code generated by an app is also ultimately viewed and transcribed by a person. The next attack targets precisely that spot.
Text message codes block attackers who hold only passwords, but to someone who has stolen the phone number itself, the evidence is handed over as well.
A Fake Site That Passes Words to the Real Site
An article in a security industry magazine in 2019 noted that while security experts agree multi-factor authentication is generally stronger than a single password, many people have come to regard multi-factor authentication as virtually unbreachable, which is far from the truth (DOI: 10.1016/s1353-4858(1930107-2). The article, quoting Roger Grimes of the security training company KnowBe4, reports that a simple phishing email can bypass many multi-factor authentication methods. Phishing is a trick where messages disguised as coming from a trustworthy source are used to extract information like passwords or to make people open harmful links and files ("Phishing and Social Engineering — Ringing the Doorbell Instead of Breaking the Lock"). The representative path by which phishing gets past multi-factor authentication is adversary-in-the-middle phishing.
Adversary-in-the-middle phishing is a setup where a fake site stands between you and the real site, reflecting the real screen as it is while passing the password and code you enter on to the real site. Such tools reflect the screen of a real service in real time, pulling out login information and session cookies along the way. A 2021 study viewed this as the newest form in a bundle of phishing tools that have automated attacks for over a decade (DOI: 10.1145/3460120.3484765). A session cookie is a pass that a site hands to a browser after a login is finished, and while that pass is valid, the site usually asks for neither password nor code again.
Let us follow a single login. When you click the link in the email, the login screen you always see appears. The only difference is the address in the address bar. The reason the screen is identical to the real one is that the fake site reflects the screen of the real site as it is, and this makes the fake page much more plausible (DOI: 10.1145/3460120.3484765). When you enter your password, the fake site passes it on to the real site. The screen where the real site asks for a code is also reflected, and the code you enter goes through the same path. When the login ends, the real site hands over the pass, and the fake site grabs that pass along the way as well. These tools even automatically harvest sessions that have finished two-step verification (DOI: 10.1145/3460120.3484765). When the attacker holds out that pass, the site asks for neither password nor code again.

The short lifespan of a one-time code is powerless against this attack. This is because the code is passed at the very moment you enter it. The authors of a 2026 Zenodo preprint comparing several multi-factor authentication methods with a scoring model evaluated it along the same lines. One-time codes received via text or email do not provide enough protection in the face of today's phishing attacks, and time-based codes generated by apps are safer but still weak against real-time attacks (DOI: 10.5281/zenodo.20812491).
Filtering out such fake sites in advance is also not easy. A 2026 experiment (preprint) spun up one such tool with default settings. A fake site mimicking one company's login screen went undetected by most public web scanners throughout the four-week experiment period. The one mimicking another company's screen was caught sporadically by only seven, and none placed it on a blocklist (DOI: 10.5281/zenodo.18830957). That meant public scanners could hardly be expected to stop fake sites in advance in that experiment, and the author views this as a major gap in current phishing detection systems.
A code that a person sees and re-enters is relayed directly at the very spot where the person was fooled.
The Habit of "Approval"
The method of pressing approval on a phone notification is convenient because there is no need to copy and paste numbers. Instead, it relies on human verification. According to a 2026 single-author paper published in a journal by a Saudi Arabian university (print quality unknown), push approval is also vulnerable to attacks where an attacker attempts to log in at the same time as the user (DOI: 10.63908/kpgnt990). Attackers also target that convenience. A 2024 proposed paper (open server version) notes in its background that attackers still commonly break in using tactics to trick users into accepting approval requests, such as sending requests multiple times until the user accepts one (arXiv:2401.11599). Approval fatigue is when login approval notifications arrive repeatedly, causing a person to press approval reflexively without checking.
A security feature designed to counter this is number matching. Number matching is a method where an approval is granted only after typing a number shown on the login screen into the phone's approval screen. This method reduces accidental approvals. However, that safety relies on the untested assumption that users actually check the number before approving (DOI: 10.63908/kpgnt990).
The aforementioned single-author paper tested that assumption. It re-examined participant-by-participant data from a controlled experiment, namely 73,829 attack attempts. The incorrect approval rate for participants who answered that they "always check" was 53.7%, higher than any other group, and one-third of them approved every attack. Confidence in security moved inversely with actual resistance to attacks (DOI: 10.63908/kpgnt990). This means that believing one checks and actually checking were different things.
In the same data, 26% of participants approved all attacks and 13.7% rejected all. Consistent differences between individuals were much larger than the device type or number length. The incorrect approval rate for fast responders was 58.4%, higher than the 38.7% for those who were not. The author interprets this as aligning with reflexive approval rather than deliberate approval (DOI: 10.63908/kpgnt990). These figures came from controlled experiment data, not measured from actual company login logs.
As an alternative, the author proposed a rule tying the approval notification to the address of the site logged into and a short time window. Its effectiveness was only shown through simulation calculations incorporating assumptions, and the author positions this as a realistic bridge between traditional push approvals and phishing-resistant methods (DOI: 10.63908/kpgnt990).
Push approvals stand on the assumption that a person checks the notification, and in experiments, that assumption varied widely from person to person.
The Day You Lost the Second Key
On the day you change or lose your phone, the key to the second door disappears with it. A 2020 master's thesis notes that 60% of users register only a single device to use as their second piece of evidence. The abstract does not state what sample this figure came from (DOI: 10.25777/3dhq-pj49). Lose that single device, and you must enter by another path. Account recovery is the procedure where a person who forgot their password or lost their second piece of evidence proves who they are by another method and gets their account back.
Users do not prepare for that day. In a 2025 study that interviewed 16 people and surveyed 95 people in Germany, most had never thought about how they would access their account if they lost their second piece of evidence, and only a few had a backup plan. Instead, they rely on the site's customer support, assuming their personal information will help them recover the account (DOI: 10.1145/3706598.3714245). "It is their responsibility to keep me going" is a quote from one participant and the title of this study.
The master's thesis mentioned earlier notes that account recovery is inherently a path that bypasses the system's main security procedure, and thus must be treated as yet another authentication procedure. That thesis evaluated four recovery methods using a self-scoring formula, determining that backup phone number recovery is the most robust against attacks, followed by recovery codes generated by the system. Among the 103 survey respondents, 45% also preferred backup phone number recovery. However, another finding of the thesis is that users are likely to ignore setup guides and enter their own phone number instead of an emergency contact (DOI: 10.25777/3dhq-pj49). The abstract does not state whether that scoring formula factored in SIM swapping separately. If the recovery path leads back to my phone number, the vulnerability of SIM swapping seen earlier can also enter through that path.
Some services look for risk signals even in the recovery procedure. This question arose as recent attacks exposed weaknesses in account recovery features outside of the login procedure. A 2024 study (preprint) investigating five services known to use risk-based authentication confirmed that the same method is used during recovery steps on Google, LinkedIn, and Amazon (arXiv:2403.11798).
This problem remains even in passwordless logins. A 2021 evaluation (preprint) that examined 12 account recovery methods for when a security key becomes permanently unusable concluded that current methods have many shortcomings and some rely on passwords again, rendering passwordless logins meaningless. The same evaluation also found a few promising recovery methods (arXiv:2105.12477). In a study surveying 118 enterprise practitioners who have handled these methods, over 60% of respondents chose account recovery as a serious loophole (arXiv:2308.08096, preprint).
No matter how sturdy you make the front door, the side door that lets in someone who lost their key becomes the actual threshold of that house.
Taking Address Verification Away from Humans
Relay phishing and approval fatigue share a common thread: both checking for a fake address and confirming notifications are left to the human. Security keys and passkeys move those tasks to machines. A private key—a key held only by the owner and never sent anywhere ("Keys and Locks — Why a Public Key Is Safe to Publish")—lies at the center. A security key is a small device plugged into a computer to use for login while keeping the private key inside, and a passkey is a set of keys created separately for each site, where the public key is left with the site and the private key is not sent to the logging-in site. Both rely on a standard called FIDO2.
Phishing resistance is the property whereby even if a user is fooled by a fake site, login proof that can be used on the real site is not produced on the spot. In this method, login proof is created tied to the address of the real site, and the browser—instead of the human—checks whether the currently accessed address is correct. Since a signature for the real site is not generated on a fake site, there is no code to hand over. The author of the Zenodo edition that established the score model above views this design, which cryptographically binds login information to the service's domain, as providing native defense against phishing and relay attacks, and rated it the highest among the compared methods (DOI: 10.5281/zenodo.20812491). A single author who analyzed approval fatigue also named this standard as a phishing-resistant method (DOI: 10.63908/kpgnt990).

That property holds only while logging in via that method. If other login paths—such as text messages, app codes, or push notifications—remain open on the same account, a fake site can surface those paths and relay them as is. Gaps on the real site side also remain. A 2025 study notes that this standard was the only authentication method practically uncracked by virtually any phishing technique up to that point (DOI: 10.1007/s11416-025-00556-2). The same study showed that when combined with other types of gaps remaining on the real site, this method can also be cracked, including cases where hardware security keys are used.
Gaps also remain around the periphery of the standard. A 2026 analysis (preprint server edition) showed that even if the cryptographic math itself is sound, the security of this method can collapse if the browser, operating system, or hardware is compromised, and concluded that the weakest point in actual deployment is usually the trusted environment surrounding the cryptographic layer rather than the layer itself (arXiv:2609.03789). A 2023 study (preprint server edition) examined cases where a browser extension is compromised or an attacker gets hold of a security key, showing that seven attacks were feasible across 10 popular web servers. Participants in user experiments failed to notice those attacks using only current error messages and notifications. The same study analyzed current browser extensions and noted that no evidence of such attacks being actually used was found (arXiv:2308.02973).
Cases where a device is infected with malware—programs created to cause harm without the user's knowledge ("Security — Unseen by Others, Unchanged in Secret, Open When Needed")—also remain. A 2022 paper (preprint server edition) points out that most current two-step methods check only a single connection without verifying individual transactions, rendering them ineffective if the device is infected (arXiv:2206.13358). What happens inside an infected device after login is completed is a matter beyond the second door.
Synchronization introduced for convenience also shifts the center of gravity. Syncing a passkey across my multiple devices reduces the worry of losing a device, but in exchange, the security of the synced passkeys concentrates primarily on the provider storing them (arXiv:2501.07380, preprint server edition). The mechanism that relieves the account recovery problem of the previous section concentrates the place that needs guarding into a single provider.
There are also costs on the user side. In a laboratory study of 87 people who tried this method on smartphones, most were willing to accept passwordless login, but the inability to support current usage patterns—such as letting someone else manage an account or using it across multiple devices—remained a barrier (arXiv:2302.07777, preprint server edition). A 2022 position paper argued that it is difficult to eliminate passwords on the web in the near future (arXiv:2211.07161, preprint server edition).
While the method tied to the site address closes the door to relay phishing as long as you log in through that method, weaker paths left open on the same account, other gaps remaining on the real site, compromise of the device and browser, and the path for when you lose your key remain unchanged.
A Different Answer for Every Attack
If you gather the evidence covered so far onto a single page, it looks like this. The contents of each cell hold true only within the conditions measured by each piece of evidence.
| Attack Vector | SMS/App Codes, Push Approvals | Address-Bound Methods (Security Keys, Passkeys) | Evidence |
|---|---|---|---|
| Logging in with stolen or reused passwords | Greatly reduces it. Apps are better than SMS, and SMS is also much better than using nothing | Demands what you possess as a second piece of evidence or is used without a password, stopping it for the same reason. Separate measured figures are not among the evidence in this article | arXiv:2305.00945 |
| Phone number hijacking and network interception | SMS codes pass the evidence along together. App codes do not go through the phone number (if recovery leads to a phone number, it falls to the account recovery row) | Does not go through the phone number (if recovery leads to a phone number, it falls to the account recovery row) | DOI: 10.1109/ic3iot60841.2024.10550217 · DOI: 10.1109/icc.2017.7997246 |
| Relay-style phishing | The code a person enters is relayed on the spot, and even the login pass passes through. Push approvals are also vulnerable to attacks logging in at the same time | As long as you log in through that method, evidence for the real site is not produced on a fake address. If another path like a code remains open for the same account, it can be relayed through that path, and attacks tied with other gaps in the real site have even breached security keys | DOI: 10.1145/3460120.3484765 · DOI: 10.63908/kpgnt990 · DOI: 10.5281/zenodo.20812491 · DOI: 10.1007/s11416-025-00556-2 |
| Repeated approval requests | Push approvals rely on human verification. Number matching also rests upon that assumption | There are no approval notifications for an attacker to trigger remotely (structural explanation — this is not what the evidence in this article measured) | arXiv:2401.11599 · DOI: 10.63908/kpgnt990 |
| Lax account recovery | If recovery is weak, they go around the second door | Same. Some recovery methods rely on passwords once again | DOI: 10.25777/3dhq-pj49 · arXiv:2105.12477 |
| Device and browser compromise | Methods that only check a single connection are ineffective in front of an infected device | Can collapse if the browser, operating system, or hardware is compromised | arXiv:2206.13358 · arXiv:2609.03789 |
If you read the table from top to bottom, what the second verification does changes. The attack in the first row is someone holding a password trying to log in from anywhere, so asking for one more piece of a different kind of evidence blocked most of them. In data measured by Microsoft researchers from their own accounts, that reduction was 99.22% overall, and 98.56% for accounts with leaked passwords. From the second row onward, attackers target the second piece of evidence itself. They hijack a phone number, intercept the code you enter on the spot, make you press approval with your own hands, or slip around through the side door of recovery. Address-bound methods close the door to relaying among those when logging in strictly through that method, while the last two rows remain separately regardless of which method you choose.
Why the Evidence Looks Mixed and What We Still Don't Know
On one side lies data stating "over 99% secure," and on the other stand papers in a row showing that "multi-factor authentication was bypassed." The two sides measured different things. Microsoft's data measured whether accounts showing suspicious activity in actual services were actually compromised. It is field data, but it is a result measured by the parties themselves on their own accounts, and the abstract does not break down the kinds of intrusion attempts involved (arXiv:2305.00945). Studies covering bypasses analyzed tools, demonstrated attacks, and conducted controlled experiments. Such studies show what is possible, but they do not measure how often that happens in actual accounts.
Thus, questions remain that cannot be answered by the evidence in this article. Research measuring through field data how many actual account takeovers were breached by relay-type phishing or consent fatigue is not among the evidence in this article. The figures for consent fatigue came from experiments, and it has not been verified whether the same rates appear in front of actual company employees' notifications.
How often to ask is also an open question. Field data on risk-based authentication showed that it is possible to single out and prompt only unfamiliar connections (DOI: 10.1145/3546069), and a university survey showed that user experience worsened when enforced on all resources (DOI: 10.1145/3313831.3376457). There are also models that take a step further from here. This model (public server version), which assumes that human attention decreases whenever verification is requested and recovers when resting, reports in a simulation run with virtual employees that a policy asking on every request was the worst. A policy asking according to risk showed the lowest risk when moderately strict, and when stricter than that, the risk rose again. The authors wrote themselves that since this result came from values they assumed, it merely shows the working principle and is not evidence for actual workplaces (DOI: 10.5281/zenodo.22849044). The relationship between the frequency of prompts and human attention is a hypothesis not yet measured in the field.
The debates on the passkey side also measure different things. The superiority of phishing resistance came from design analysis and scoring models, the remaining gaps came from demonstrations and threat analysis, and the costs of recovery and usability came from surveys and laboratory studies. The three types of evidence do not refute each other; rather, they look at different sides of the same approach.
Significance — Where the Second Door Closes and Where It Opens
The statement "Turning on two-factor authentication keeps you safe" has strong evidence when someone else tries to log in with a stolen or reused password. Data measured by Microsoft researchers on their own accounts showed the risk dropped by more than 98%. Where that statement fails is when attackers target the second piece of evidence itself. In front of SIM swapping attacks, fake sites that hand over the code you enter on the spot, approvals you tap out of habit, and lax account recovery, even the second door can open.
The statement "SMS verification is useless" goes too far. In the same data, SMS also raised security significantly compared to not using it at all. As the author of an open server edition evaluated, the criticism that SMS codes do not provide enough protection against today's phishing holds true in front of attacks that hand over codes on the spot and attacks targeting phone numbers themselves. The fact that it is worse than apps is also in the same data.
What second verification blocks depends on what else it asks, and no method protects account recovery and device takeover in their place.
What multi-factor authentication, one-time codes, security keys, and passkeys are can be found in "Passwords and Passkeys — How Do You Prove You Are You?". The experiment where people who believe "I always check" approved the most mistakes connects to "Simulated Phishing Training — What Changes When You Ring a Fake Doorbell?", which asks how far defenses relying on human attention can endure. "Password Expiration Rules — When You Make People Change Often, What Do They Actually Change?" covers what the first door that the second door blocks—namely, password rules—actually changes.
Source Papers
- "How effective is multifactor authentication at deterring cyberattacks?" (2023, public server edition) — arXiv:2305.00945 — Microsoft researchers (all authors affiliated) used user data showing suspicious activity in their Azure Active Directory. Over 99.99% of multi-factor authenticated accounts were safe, reducing overall risk by 99.22% and leaked accounts by 98.56%. Dedicated apps are better than text messages, but both are significantly better than no authentication. Strongly recommends default application.
- "Data Breaches, Phishing, or Malware?" (2017) — DOI: 10.1145/3133956.3134067 — Tracked potential victims of keylogger and phishing tool bundles between 2016.3 and 2017.3, accounting for 1,900,000,000 leaked accounts. In Google's case, 7% to 25% of leaked passwords matched the victims' Google accounts. Adding risk signals such as past login locations and devices mitigates theft risk.
- "Pump Up Password Security! Evaluating and Enhancing Risk-Based Authentication on a Real-World Large-Scale Online Service" (2022) — DOI: 10.1145/3546069 — Risk-based authentication requires re-authentication if login characteristics differ significantly from previous values. National security agencies recommend it, and users perceive it as more convenient than equivalent two-factor authentication and equally secure, but adoption is very low. Over 3,300,000 users and roughly 30 million login attempts, over 1 year of field data, benefits after a few logins.
- "How Mandatory Second Factor Affects the Authentication User Experience" (2020) — DOI: 10.1145/3313831.3376457 — Phased introduction of mandatory two-factor authentication at a large public university, multiple surveys and authentication logs. When only sensitive systems were mandatory, experience and acceptability did not change; when forced on all resources, they worsened.
- "“It's not actually that horrible”" (2018) — DOI: 10.1145/3173574.3174030 — Observed rollout at Carnegie Mellon University. Annoying, but believed to be quite easy to use and more secure. The difference between mandatory and voluntary adopters is smaller than expected.
- "Understanding the Implications of SIM Card Swap Fraud in India: A Comprehensive Study" (2024) — DOI: 10.1109/ic3iot60841.2024.10550217 — SIM card swapping involves persuading a telecom carrier to move a number to an attacker's SIM, changing the password tied to the number to access banks and social media. High-value cryptocurrency theft cases.
- "SMS and one-time-password interception in LTE networks" (2017) — DOI: 10.1109/icc.2017.7997246 — That text messages can be intercepted via SS7 has been known since 2014. Shows that text messages can be intercepted regardless of device and OS even in diameter-based LTE networks, and presents the impact on Google, Microsoft, and Twitter services.
- "The many ways to hack 2FA" (2019, industry magazine interview) — DOI: 10.1016/s1353-4858(1930107-2 — Experts agree that multi-factor authentication is generally stronger, but the perception that it is almost uncrackable is wrong, and many methods can be bypassed with a simple phishing email (Roger Grimes, KnowBe4).
- "Catching Transparent Phish: Analyzing and Detecting MITM Phishing Toolkits" (2021) — DOI: 10.1145/3460120.3484765 — Man-in-the-middle phishing toolkits are malicious reverse proxies that mirror the real screen while stealing login information and session cookies, automating the harvesting of sessions that have completed two-factor authentication, and making fake pages much more plausible.
- "COMPARATIVE ANALYSIS OF MODERN MULTI-FACTOR AUTHENTICATION METHODS IN CYBERSECURITY SYSTEMS" (2026, public server edition) — DOI: 10.5281/zenodo.20812491 — Comparison of weighted sum score models. Text and email codes are inadequate for modern phishing, app time-based codes are safer but vulnerable to real-time attacks, push relies partly on human factors, and FIDO2/WebAuthn binding securely to domains by password scores the highest.
- "DETECTION AND EVASION ANALYSIS OF MAN-IN-THE-MIDDLE PHISHING ATTACKS" (2026, public server edition) — DOI: 10.5281/zenodo.18830957 — Experiment running man-in-the-middle phishing toolkits with default settings. One fake site evaded most public web inspectors for all 4 weeks, while another was detected erratically in only seven places, with no blocklist listings.
- "Reducing Usefulness of Stolen Credentials in SSO Contexts" (2024, public server edition) — arXiv:2401.11599 — While multi-factor authentication helps stop valid credential attacks, attackers still commonly break in by repeatedly pushing approval requests to get them accepted. Proposes a token-based registration architecture.
- "The Verification Illusion: Hardening Push-Based MFA with Context-Rich Number Matching" (2026, journal, single author, page quality unknown) — DOI: 10.63908/kpgnt990 — Controlled push experiment data per participant (73,829 attack attempts). The "always check" group had the highest false approval rate at 53.7%, and one-third of them approved all attacks. 26% approved all and 13.7% rejected all, fast responders 58.4% vs 38.7%. Proposes rules tied to address and time windows, effectiveness only via simulation calculations.
- "When Friction Becomes Risk: A Behaviour-Aware Adaptive Access Control Model for Hybrid Workforces" (public server edition) — DOI: 10.5281/zenodo.22849044 — A model where attention decreases with each confirmation and recovers with rest. In a 400 virtual user and 60-day simulation, a policy asking every time is the worst, and risk-based has the lowest risk at medium strictness. The author notes that because the results are from assumed values, they are not real workplace evidence.
- "Account Recovery Methods for Two-Factor Authentication (2FA): An Exploratory Study" (2020, master's thesis) — DOI: 10.25777/3dhq-pj49 — 60% of users register only a single second evidence device (sample size unknown). Account recovery is a bypass of the main security procedure and should be treated as an alternative authentication procedure. Self-evaluated that backup phone number recovery is the strongest against attacks among the four methods. Survey of 103 people, 45% prefer backup phone number recovery, likelihood of putting one's own number instead of an emergency contact.
- "“They are responsible for ensuring that I can continue to use the service.” Investigating Users' Expectations Towards 2FA Recovery in Germany" (2025) — DOI: 10.1145/3706598.3714245 — 16 interviews and 95 surveys. Most have never thought about what happens if they lose their second piece of evidence, few have backup plans, expect to recover through personal information, and rely on customer support.
- "Is It Really You Who Forgot the Password? When Account Recovery Meets Risk-Based Authentication" (2024, public server edition) — arXiv:2403.11798 — Recent attacks expose weaknesses in account recovery features. Examined five services using risk-based authentication, confirming risk-based account recovery in Google, LinkedIn, and Amazon.
- "Evaluation of Account Recovery Strategies with FIDO2-based Passwordless Authentication" (2021, public server edition) — arXiv:2105.12477 — Heuristic evaluation of 12 recovery methods. Current methods have many flaws, and some rely on passwords, rendering passwordless authentication meaningless. Also found promising recovery methods.
- "Challenges with Passwordless FIDO2 in an Enterprise Setting: A Usability Study" (2023, public server edition) — arXiv:2308.08096 — 118 practitioners. Serious gaps such as account recovery (chosen by over 60%).
- "Beyond the Trust Boundary: A Critical Reassessment of the FIDO2 Threat Model" (2026, public server edition) — arXiv:2609.03789 — Even if cryptographic primitives are intact, browser, OS, and hardware takeovers can break FIDO2 security. The main weakness is usually the surrounding trusted environment rather than the crypto layer.
- "A Security and Usability Analysis of Local Attacks Against FIDO2" (2023, public server edition) — arXiv:2308.02973 — Browser extension takeover and physical security key access. Demonstrated 7 attacks across 10 popular web servers, participants failed to notice attacks with current messages. No evidence of actual attacks in current extension analysis.
- "FIDO2 With Two Displays-Or How to Protect Security-Critical Web Transactions Against Malware Attacks" (2022, public server edition) — arXiv:2206.13358 — Most current methods authenticate only the session, not individual transactions, so they are ineffective if the device is infected with malware. Proposes a new method.
- "Defeating FIDO2/CTAP2/WebAuthn using browser in the middle and reflected cross site scripting" (2025) — DOI: 10.1007/s11416-025-00556-2 — Most multi-factor authentication does not stop browser-in-the-middle attacks, but FIDO2 was practically the only uncrackable method. Showed that all methods including hardware dongles can be defeated by attacks combined with reflected XSS vulnerabilities.
- "Device-Bound vs. Synced Credentials: A Comparative Evaluation of Passkey Authentication" (2025, public server edition) — arXiv:2501.07380 — Synchronization relieves worries about losing devices, but the security of synced passkeys rests primarily on the passkey provider.
- "FIDO2 the Rescue? Platform vs. Roaming Authentication on Smartphones" (2023, public server edition) — arXiv:2302.07777 — 87 lab participants. Most intend to accept passwordless authentication, barriers include lack of support for account delegation and multi-device usage.
- "Is FIDO2 Passwordless Authentication a Hype or for Real?: A Position Paper" (2022, public server edition) — arXiv:2211.07161 — The stance that it is difficult to eliminate passwords on the web in the near future.
Sources (26)
- How effective is multifactor authentication at deterring cyberattacks?arXiv:2305.00945
- Data Breaches, Phishing, or Malware?DOI 10.1145/3133956.3134067
- Pump Up Password Security! Evaluating and Enhancing Risk-Based Authentication on a Real-World Large-Scale Online ServiceDOI 10.1145/3546069
- How Mandatory Second Factor Affects the Authentication User ExperienceDOI 10.1145/3313831.3376457
- It's not actually that horribleDOI 10.1145/3173574.3174030
- Understanding the Implications of SIM Card Swap Fraud in India: A Comprehensive StudyDOI 10.1109/ic3iot60841.2024.10550217
- SMS and one-time-password interception in LTE networksDOI 10.1109/icc.2017.7997246
- The many ways to hack 2FADOI 10.1016/s1353-4858(19)30107-2
- Catching Transparent Phish: Analyzing and Detecting MITM Phishing ToolkitsDOI 10.1145/3460120.3484765
- COMPARATIVE ANALYSIS OF MODERN MULTI-FACTOR AUTHENTICATION METHODS IN CYBERSECURITY SYSTEMSDOI 10.5281/zenodo.20812491
- DETECTION AND EVASION ANALYSIS OF MAN-IN-THE-MIDDLE PHISHING ATTACKSDOI 10.5281/zenodo.18830957
- Reducing Usefulness of Stolen Credentials in SSO ContextsarXiv:2401.11599
- The Verification Illusion: Hardening Push-Based MFA with Context-Rich Number MatchingDOI 10.63908/kpgnt990
- When Friction Becomes Risk: A Behaviour-Aware Adaptive Access Control Model for Hybrid WorkforcesDOI 10.5281/zenodo.22849044
- Account Recovery Methods for Two-Factor Authentication (2FA): An Exploratory StudyDOI 10.25777/3dhq-pj49
- They are responsible for ensuring that I can continue to use the serviceDOI 10.1145/3706598.3714245
- Is It Really You Who Forgot the Password? When Account Recovery Meets Risk-Based AuthenticationarXiv:2403.11798
- Evaluation of Account Recovery Strategies with FIDO2-based Passwordless AuthenticationarXiv:2105.12477
- Challenges with Passwordless FIDO2 in an Enterprise Setting: A Usability StudyarXiv:2308.08096
- Beyond the Trust Boundary: A Critical Reassessment of the FIDO2 Threat ModelarXiv:2609.03789
- A Security and Usability Analysis of Local Attacks Against FIDO2arXiv:2308.02973
- FIDO2 With Two Displays-Or How to Protect Security-Critical Web Transactions Against Malware AttacksarXiv:2206.13358
- Defeating FIDO2/CTAP2/WebAuthn using browser in the middle and reflected cross site scriptingDOI 10.1007/s11416-025-00556-2
- Device-Bound vs. Synced Credentials: A Comparative Evaluation of Passkey AuthenticationarXiv:2501.07380
- FIDO2 the Rescue? Platform vs. Roaming Authentication on SmartphonesarXiv:2302.07777
- Is FIDO2 Passwordless Authentication a Hype or for Real?: A Position PaperarXiv:2211.07161