
Paperis Articles
Passwords and Passkeys — How Do You Prove You Are You?
Something you know, have, or are; hashing and salt; password reuse; SMS codes and SIM swaps; passkeys and biometrics — what each stops and what it doesn't
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 →Passwords and Passkeys — How Do You Prove You Are You?
Three Times in the Morning: "Who Goes There?"
On the subway to work, you lift your phone. The screen recognizes your face and unlocks. When you open the banking app, it asks for your ID and password, and then immediately asks for a six-digit number that arrived by text message. In the space of a few minutes, the machine has asked "Who goes there?" at the door three times.
The bank's computer cannot see a human. What it can see is only what you hand over. Memorized characters, a number received on the phone in your hand, a face in front of the camera. So if someone else hands over the exact same things, the machine accepts that person as you.
This article follows four questions. What kinds of evidence can be handed to a machine? How are passwords stored on the bank's computers? Why does a password leaked from one place open doors elsewhere? What do newly introduced methods block, and what can they not stop?
Checking at the Door and Permission Inside — Authentication and Authorization
A login screen has two fields. In the ID field, you say who you are, and in the password field, you present evidence that the claim is true. This procedure has traditionally been divided into two parts: revealing who you are and submitting a password (DOI: 10.1145/322796.322806).
Authentication is the act of verifying whether the person trying to enter right now is truly that person. In short, it is the process of confirming identity (DOI: 10.1145/3687264).
After passing through the door, it is separately determined which rooms inside the house you can enter. Authorization is the act of permitting a verified person to see what they can see and change what they can change. An employee logging into a company system and being allowed to open only their own department's folder is authorization. One way to determine authorization is to check a person, a target, and the nature of the intended action against pre-established rules (DOI: 10.6028/nist.sp.800-162, a standard document defining attribute-based approaches). The ID states "Who are you?", authentication answers "Are you really that person?", and authorization answers "What is that person permitted to do?".
The two tasks are connected. Attacks targeting authentication allow an intruder to pretend to be a real user and access that person's resources, which is why it has become one of the primary pathways for attacks (DOI: 10.1145/3734864). If someone else passes your authentication, that person uses what is permitted to you under your name.
What You Know, What You Have, and Who You Are
A password lives in your head, a phone in your pocket, a fingerprint on your fingertip. Authentication factors are the kinds of evidence you produce to show you are you. They are commonly divided into three: something you know like a password, something you have like a small device, and something you carry on your body like a fingerprint or a face. Other factors are used as well (DOI: 10.1145/3734864). Online banks also use all three of these types, and each of the three has its own strengths and weaknesses (DOI: 10.1109/access.2023.3346045).
The three pieces of evidence fail in different ways. If something you know is peeked at by someone else or leaks from somewhere, that person knows it too, and it is hard for you to notice that fact. If something you have is lost or stolen, you usually notice. However, like the phone number we will see later, there are cases where the physical item stays in your hand while only the evidence inside it moves to someone else. Body traits are rarely lost, but once a way to mimic them appears, they cannot be swapped out like a password.
Because they fail in different ways, demanding two different types of evidence together means that unless both fail at once, even if one fails, the other remains. The method of asking for multiple pieces of evidence, which we will look at later, came from this idea.
Servers Must Not Store Passwords in Plain Text
In 2012, the passwords of 6.5 million users of the professional networking site LinkedIn appeared on a criminal underground market. What appeared were values obtained by transforming each password once. A 2012 short commentary covering this event highlighted two words from the news as matters of concern (DOI: 10.1145/2246036.2254400, short commentary). One was SHA1, the name of the method used for the transformation, and the other was the statement that something which should have been added to the transformation was missing.
If the computer receiving the login—the server—records passwords literally, the moment that list leaks, every user's password is exposed. Therefore, passwords are commonly converted into hashes before being recorded (DOI: 10.4028/www.scientific.net/amm.347-350.2706). A hash is a way to reduce text of any length into a single short value of fixed length (What Is a Blockchain). Calculating a password backward from its hash value has been made ridiculously expensive, but it has only been made that way, not mathematically proven impossible. The remaining path for an attacker is to hash candidate passwords one by one and match them up.
When you log in, the password you typed travels over an encrypted connection to the server, and the server hashes it in the same way and simply checks whether it matches the recorded value. The server knows whether you provided the correct password without ever recording your password. The fact that the password travels across the network every time you log in will become important again later.
There is a vulnerability in this method. The same password always produces the exact same hash. Therefore, attackers can precompute tables of hashes for common passwords and simply compare them against stolen values. The missing element pointed out by the LinkedIn commentary is a device that patches this vulnerability.
A salt is a random value chosen separately for each user, which is appended to the password and hashed together with it. To prevent attacks that find passwords using precomputed tables, the general recommendation is to apply the hash to the combined salt and password (DOI: 10.1109/acsat.2012.49). A login method recommended by industry standards also requires the server to record the password's hash alongside a random salt (DOI: 10.1109/tdsc.2020.3040776).
When salts differ for each person, identical passwords are recorded as completely different values. Precomputed tables become useless, and attackers must crack each person's password separately. The salt itself is not a secret, so it is recorded right next to the hash.

This still does not block the path of recovery. An attacker who breaches a service and gets hold of salted hashes can still recover passwords by putting in an effort proportional to the number of candidate passwords (DOI: 10.14722/ndss.2014.23167). Therefore, in practice, the number of repetitions of the hash along with the salt is increased, significantly raising the workload for such attacks (DOI: 10.1109/tit.2005.853307).
This task rests in the hands of the developers building the service, and it is frequently gotten wrong. Storing passwords is a complex task, and there is a history of failures due to human error. The consequences caused by a single developer who leaves out hashes and salts can be far greater than those caused by a single user who picks a poor password (DOI: 10.1145/3133956.3134082, raising issues from a qualitative study of 20 students).
Hashes and salts only make recovering leaked passwords expensive; they do not make them impossible to recover.
When One Place Leaks, Another Door Opens: Reuse and Credential Stuffing
Accounts keep growing, but passwords rarely do. In a 2006 study investigating the password habits of 49 college students, most had three or fewer passwords. Accounts multiplied over time while passwords did not, leading to an increasing rate of reuse. Students wanted to protect financial information and private chats, but using the same password made management easier (DOI: 10.1145/1143120.1143127).
When you use the same password across multiple accounts, a breach in one opens the path for an attacker to take over multiple accounts (DOI: 10.1145/1143120.1143127). Credential stuffing is an attack where stolen passwords from one place are used to log into a victim's other accounts. Credential is the English word for login information, and the name comes from filling stolen login information into the login fields of other places.
Slightly modified passwords are not safe either. These attacks work because people use the same or similar passwords across multiple sites (DOI: 10.1109/sp.2019.00056). Researchers trained a model on how people similarly modify passwords using 1.4 billion leaked email-password pairs and ran simulations. If an attacker knew one of a person's other passwords, more than 16% of accounts were breached in under 1,000 attempts, even with the latest defenses at the time. This attack actually worked on the login service of a major university as well. As a way to block it, the researchers proposed a personalized password strength meter that warns users when they choose a password vulnerable to this attack (DOI: 10.1109/sp.2019.00056).
Service providers are also taking action. It has become an industry best practice to check in advance whether a user's login information is already included in known leak lists (DOI: 10.1145/3319535.3354229). However, these checks only look for whether the exact same password leaked and cannot filter out slightly modified variants. This is a limitation pointed out by a public server version paper that designed a verification service capable of filtering out even variants (DOI: 10.48550/arxiv.2109.14490, preprint).
The simplest way to break reuse is to use a different password for each site, but even as accounts multiplied, the number of passwords a human can memorize did not. A password manager is a program that remembers passwords for multiple sites on your behalf and retrieves them when you log in. The 2006 study also discussed alternatives, covering the evolution of password managers alongside website authentication methods (DOI: 10.1145/1143120.1143127).
When five widely used web-based password managers from 2014 were analyzed, four of them allowed an attacker to find login information for any site. The authors concluded that managers in that form of the era might not adequately protect user secrets, and urged that multiple layers of defense must be built to protect managers (DOI: 10.21236/ada614474). These findings looked at five products from 2014. Tools that break reuse gather all the keys onto a single ring, and protecting that ring becomes a new homework assignment.
Whether rules forcing users to change passwords periodically actually help is a matter of separate debate.
One More Piece of Evidence — Multi-Factor Authentication and One-Time Codes
You entered your password correctly, but your banking app asks for six more digits. Multi-factor authentication is a method that demands two or more different types of evidence among what you know, what you have, and a bodily characteristic. Requiring two different types of evidence is commonly called two-factor authentication. Asking the same type twice, like adding a security question to a password, is not multi-factor authentication.
Multi-factor authentication raises the hurdle that an impersonator must clear and is generally considered safer than methods asking just one. However, it is not perfect. Design or implementation flaws can leave critical weaknesses, and a systematic analysis examining multi-factor authentication protocol designs across several domains found security flaws in most of the designs it reviewed (DOI: 10.1145/3734864).
A one-time code is a number that no longer works once used or after a short time. According to a 1998 one-time password standard document, the original target of this method was an attack where someone eavesdrops on communications to intercept a password and later replays it as-is. Since a used code no longer works, eavesdropping on it is useless. That standard document notes that this method does not prevent attacks that trick people or intervene in real-time in the middle (DOI: 10.17487/rfc2289, standard document).
Codes that change over time have the advantage of a short lifespan. The authors of that standard foresaw that having a common calculation method would lead to wider use of two-factor authentication on the internet (DOI: 10.17487/rfc6238, standard document).
There are also places that multi-factor authentication cannot block. Multi-factor authentication lowers the success probability of attacks where someone guesses a password and tries it at the login prompt. However, if a server is breached and salted hashes leak, an attacker can recover passwords from them, and existing two-factor methods do not prevent this. The recovered passwords can be reused on other sites that ask only for passwords. The same research team proposed a new method improving both of these directions (DOI: 10.14722/ndss.2014.23167).
Multi-factor authentication raises the hurdle, but what it blocks depends on which evidence you add.
The Vulnerable Spot of Codes Received by Text
One-time codes received via text messages are widely used in mobile apps. Many popular apps let users log in using just a text message code without a password (DOI: 10.14722/ndss.2021.24212). However, text messages were not designed as a secure channel from the beginning (DOI: 10.1145/3359789.3359828). When an automated analysis of 3,303 popular Android apps was conducted in 2019, 544 of them used text message codes, and among them, 536 (98.5%) violated one or more security rules extracted by researchers from standard documents (DOI: 10.1145/3359789.3359828).
Gaps also appeared within the same mobile phone. A 2021 study examined a scenario where an attacker placed a single app without special permissions on a victim's phone. As a result, design flaws emerged even in features directly provided by the operating system, making it possible to completely hijack accounts across 36 apps whose combined installations reached hundreds of millions. Among them were widely used messenger apps around the world. The researchers proposed a safer method of authenticating via text messages and formally proved its security (DOI: 10.14722/ndss.2021.24212).
A text message code goes to the person receiving text messages on that phone number. A SIM swapping attack is an attack where an attacker induces a telecom 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, enabling them to access bank and social media accounts (DOI: 10.1109/ic3iot60841.2024.10550217). SIM swapping is one of several ways to bypass one-time codes. Deceiving attacks and man-in-the-middle attacks seen earlier also target the same codes (DOI: 10.17487/rfc2289, standard document), and ways of intercepting text messages using weaknesses in the telecommunications network itself are also discussed (DOI: 10.30574/wjarr.2025.26.1.1181, 2025 review article).
Text message codes still raise the barrier compared to having only a password. A person who has only obtained a password cannot receive the code sent to my phone. A review article summarizing authentication methods for online banking expects that the security of online banking will improve as two-factor authentication and multi-factor authentication increase, while warning that new threats will continue to emerge (DOI: 10.1109/access.2023.3346045). In a systematic review examining 13 authentication tools for payment systems, 33% relied primarily on one-time codes despite the existence of more advanced methods (DOI: 10.1016/j.sysarc.2025.103402).
Text message codes rest on the assumption that the person receiving text messages on that phone number is none other than myself, and when the number is handed over, the proof goes with it.
Logging In Without Sending a Secret
Some sites display a button asking you to log in with your fingerprint instead of a password field. What passes back and forth in this brief moment are public keys and digital signatures. In "Keys and Locks — Why a Public Key Is Safe to Publish", a public key was an open lock put out for anyone to use, and a private key was a key kept only by the owner and never sent anywhere. A digital signature was a mark that only someone holding the private key could make, and that anyone could verify using its matching public key.
A security key is a small device kept plugged into a computer for login, with the private key safely stored inside. Users plug this device into the computer's USB port and log in with a signature (DOI: 10.1145/3600160.3600174). When logging in, the site sends a challenge, and the security key signs that challenge with the private key and returns it. To protect user information, security keys use a different key pair for each service—meaning a set of a public key and a private key created together and matched only to each other (DOI: 10.56553/popets-2022-0129).
A passkey is a key pair created separately for each site, where the public key is left with that site and the private key is a login method never sent to the site. The device holding the private key can be the computer itself or a nearby phone. Users log in simply by unlocking that device (DOI: 10.1145/3664476.3664496). Providing a fingerprint is the act of opening your device. While a password travels to the site every time you log in, what goes from a passkey to the site is a signature. By combining the possession of a physical device with a fingerprint or lock code used to open it, it uses two different types of evidence even without a password. Security keys and passkeys rely on a standard called FIDO2, which is a globally used passwordless login standard (DOI: 10.1109/sp46215.2023.10179454).

Many passkeys are used alongside a synchronization feature that safely encrypts and transfers the private key to other devices under the same account. Even though the private key does not go to the site, it moves between your own devices, meaning you can still log back in even if you lose one device. However, that synchronization becomes one of the remaining risks (DOI: 10.57166/riqchary/v8.n2.2026.3).
Because only the public key remains on the site, even if the site is breached, the open lock is all an attacker gets. Tracing the key backward from that lock is still too expensive for anyone to pull off, though it has not been mathematically proven impossible ("Keys and Locks"). Because the keys differ for each site, a key from one place will never open a door anywhere else.
This method also resists phishing—tricks that use messages disguised as coming from a trustworthy source to extract information like passwords or to make you open harmful links and files (Phishing and Social Engineering, another piece in this series). Because login information is bound to the site address, it reduces phishing attacks that intercept or directly relay information in the middle (DOI: 10.57166/riqchary/v8.n2.2026.3, 2026 systematic review; paper quality unknown). Because passkeys are keys created for the real site's address, a signature for that site will not be produced on a fake site with a different address. The browser, not the human, checks whether the address matches. A 2025 study notes that this standard was practically the only authentication method up to that point that had not been bypassed by any phishing technique. The same study showed that when combined with other types of flaws remaining on the real site, even this method can be bypassed, including cases using hardware security keys (DOI: 10.1007/s11416-025-00556-2).
Flaws exist elsewhere as well. Some attacks left outside the scope when designing the standard were easily executed in practice. Extracting PINs—the short passwords set on security keys—impersonation, and registering fake keys have been demonstrated on commercially available devices (DOI: 10.1145/3600160.3600174).
When the private key resides only on that device, losing the device also means losing the way in. Since losing your authentication device locks you out of web services, a 2020 study notes that usable recovery methods that preserve the original design are urgently needed, and analyzes a proposal that keeps a separate backup authentication device (DOI: 10.1145/3372297.3417292). If the recovery path is flimsy, it leaves a window open right next to a sturdy door. The same 2026 review reports that risks remain if the device itself is compromised, if sessions are hijacked after logging in, or if settings are misconfigured, and concludes that this method should be brought in as part of identity management that also covers recovery, device protection, and session security (DOI: 10.57166/riqchary/v8.n2.2026.3).
Passkeys leave no secrets for servers to steal and eliminate the need to type secrets into sites, but surrounding flaws and the path back when a device is lost still remain.
Confirmation by the Body — Two Directions Where Biometric Authentication Fails
On days when you wear a mask, your facial lock often fails to unlock. Biometric authentication is verification that someone is who they claim to be using bodily traits like fingerprints, faces, and irises. It has become important because it is convenient and widely used, and among those, facial recognition is one of the most widely used methods while also being the target of various attacks (DOI: 10.1145/3687264).
Biometric authentication fails in two directions. These are the mistake of wrongly accepting someone else as me, and the mistake of wrongly rejecting me as someone else, and no system can make both of them zero (DOI: 10.1109/maes.2005.1396793). The performance of a biometric verification system is judged by these two ratios (DOI: 10.1109/34.598237). If the standard is set strictly, the instances of accepting others decrease while the instances of rejecting oneself increase, and if it is set loosely, the opposite happens.
Forging actually works too. Facial recognition is vulnerable to forgeries such as printed photos or replayed videos (DOI: 10.3390/bdcc7010037). Therefore, research to screen whether what is presented in front of the camera is a forgery has been active over the past 20 years (DOI: 10.1145/3687264).
In an experiment from 2006, two widely used commercial iris cameras at the time accepted fake irises created from prints 73% and 15% of the time, respectively. Three liveness detection methods created by the same researchers accepted zero fakes in their data. The rate of rejecting real ones was 2.8% for the first method and 0 for the other two (DOI: 10.1109/ccst.2006.313440). Although this is the result of equipment from 20 years ago, it shows both that forgery actually worked on commercial equipment and that the blocking method worked on the researchers' data.
This is evidence that biometric authentication also fails, and the threshold is placed somewhere between the mistake of accepting others and the mistake of pushing me away.
The Next Morning, Three More Checks
Your phone unlocks by looking at your face. That is biometric authentication. If the standard is strict, the days it rejects you grow, and if the system cannot catch counterfeits, it might be unlocked by a single photo.
You put your ID into a banking app to say who you are, and prove that claim with a password. The bank server did not write down your password. It only hashes the characters you typed along with your salt, and compares it to the value it wrote down. But if you used the same password at a shopping mall you joined a few years ago and that place was breached, an attacker at the bank's door already holds the correct password. That is the spot credential stuffing targets.
That is why the bank asks for a one-time code by text message one more time. An attacker holding only the password is blocked here. If your phone number moved to someone else's SIM through a SIM swapping attack, the code goes to that person too.
If the bank made you use passkeys, the scene changes. There is no password to type in, and the phone merely signs a question sent by the bank. Even if the bank is breached, there are only public keys there. Yet if another gap remains on the bank's website side, this door can also be breached. If the passkey was only on that phone, finding a way back in on the day you lose the phone becomes the problem, and if you synced it, guarding that sync account remains.
Once you pass through the door, authorization begins. Your account is visible, and other people's accounts are not.
No single method blocks all attacks, and each method differs in which attacks it blocks and which it fails to block.
Where to Look Further
The device that passkeys lean on is in "Keys and Locks — Why a Public Key Is Safe to Publish". That piece covers why it is safe even after handing out an open lock, and the fact that this safety relies only on expensive computation values rather than being proven.
Another way to prove you know a secret without handing over the secret is in "Zero-Knowledge Proofs: Proving the Truth Without Revealing the Data".
If you keep the key on your device, the path when you lose it becomes a problem. What changes between holding the key yourself and leaving it to someone else is covered by "Where Are My Coins? — Wallets, Exchanges, and Who Holds the Key".
How the public-key method fares in front of quantum computers leads to "Will Quantum Computers Really Break All Encryption? — Two Misconceptions: "All" and "Later"". There is an analysis showing that the passkey standard can also be used in a way that withstands quantum computers if certain conditions and small extensions are added (DOI: 10.1109/sp46215.2023.10179454).
Other parts of this series take charge of the basics: "Phishing and Social Engineering" covers phishing, "Encryption" covers encryption itself, and "Security" covers what security protects.
Source Papers
- "Users are not the enemy" (1999) — DOI: 10.1145/322796.322806 — Security relies on authentication devices such as passwords, and authentication procedures are traditionally split into two steps: identification and passwords. The human factor must be built into the design.
- "Presentation Attack Detection: A Systematic Literature Review" (2024) — DOI: 10.1145/3687264 — Identity authentication is the process of verifying identity. Biometric authentication is convenient, widely used, and crucial; facial recognition is the most widely used while also facing various attacks. Forgery detection has been studied for 20 years.
- "Unveiling the Covert Vulnerabilities in Multi-Factor Authentication Protocols: A Systematic Review and Security Analysis" (2025) — DOI: 10.1145/3734864 — Authentication attacks are the primary attack channel leading to resource access through impersonation. Factors include something you know, something you have, and something you are. Multi-factor authentication raises the bar and is generally safer, yet not perfect, and design flaws were found in most evaluated protocols.
- "Online Banking User Authentication Methods: A Systematic Literature Review" (2023) — DOI: 10.1109/access.2023.3346045 — Pros and cons of knowledge-, biometrics-, and possession-based authentication along with online banking authentication threats. The expansion of 2FA and MFA will improve online banking security, but new threats will also emerge.
- "LinkedIn Password Leak: Salt Their Hide" (2012, short commentary) — DOI: 10.1145/2246036.2254400 — 6.5 million LinkedIn passwords hashed with SHA-1 without a salt appeared in the criminal underground market. "Unsalted" and "SHA-1" are causes for concern.
- "Security Analysis of MD5 Algorithm in Password Storage" (2013) — DOI: 10.4028/www.scientific.net/amm.347-350.2706 — Hashes are commonly used to convert passwords into theoretically uncrackable values. Discussion on salts and repeated hashing, proposing key stretching to slow down computation.
- "Security Analysis of salt||password Hashes" (2012) — DOI: 10.1109/acsat.2012.49 — Combining a salt and a password to hash is a general recommendation to prevent pre-calculated dictionary attacks. Analysis of subtle weaknesses in prefix salt methods.
- "Quantum-Safe Round-Optimal Password Authentication for Mobile Devices" (2020) — DOI: 10.1109/tdsc.2020.3040776 — Industry standards recommend asymmetric PAKE, having servers store password hashes alongside random salts. Proposes a quantum-resistant version.
- "Two-Factor Authentication Resilient to Server Compromise Using Mix-Bandwidth Devices" (2014) — DOI: 10.14722/ndss.2014.23167 — Two-factor authentication reduces online guessing, but traditional methods fail to stop offline dictionary attacks by attackers who breach services to obtain salt-friendly hashes, and recovered passwords can be reused on other sites. Proposes a new protocol improving both directions.
- "Why Do Developers Get Password Storage Wrong?" (2017) — DOI: 10.1145/3133956.3134082 — Password storage has frequently failed due to human error, and the consequences of developers omitting hashes and salts are far greater. Qualitative usability study of 20 computer science students.
- "Password management strategies for online accounts" (2006) — DOI: 10.1145/1143120.1143127 — 49 college students. Most had three or fewer passwords; as accounts increase while passwords do not, reuse increases. Reuse allows the theft of one password to compromise multiple accounts. Discusses changes in website authentication and password managers.
- "Might I Get Pwned: A Second Generation Compromised Credential Checking Service" (2021, preprint) — DOI: 10.48550/arxiv.2109.14490 — Credential stuffing logs into victim accounts using stolen passwords. Existing breach checking services check only exact password matches, failing to stop mutation attacks.
- "Beyond Credential Stuffing: Password Similarity Models Using Neural Networks" (2019) — DOI: 10.1109/sp.2019.00056 — Targeted attacks work because people use the same or similar passwords. Trained on 1.4 billion leaked pairs, knowing one different password compromises over 16% of accounts in under 1,000 tries even against state-of-the-art defenses (simulation). Also effective in university case studies. Proposes an individual strength meter.
- "Protocols for Checking Compromised Credentials" (2019) — DOI: 10.1145/3319535.3354229 — Checking in advance whether user credentials exist in known leaks is an industry best practice. Leak analysis of existing checking protocols and proposal of a new protocol.
- "The Emperor's New Password Manager: Security Analysis of Web-based Password Managers" (2014) — DOI: 10.21236/ada614474 — In 4 out of 5 web-based password managers, attackers could figure out credentials for arbitrary sites. Current forms may not provide sufficient security, and defense-in-depth is recommended.
- "A One-Time Password System" (1998, standard document) — DOI: 10.17487/rfc2289 — One-time passwords are designed to prevent replay attacks where intercepted passwords are used again. They do not stop social engineering or active attacks.
- "TOTP: Time-Based One-Time Password Algorithm" (2011, standard document) — DOI: 10.17487/rfc6238 — Time-based one-time passwords have short lifespans, which is desirable for security. A common algorithm will help spread two-factor authentication.
- "On the Insecurity of SMS One-Time Password Messages against Local Attackers in Modern Mobile Devices" (2021) — DOI: 10.14722/ndss.2021.24212 — Many popular apps use text message one-time codes as their sole authentication factor. In a scenario where an attacker holds an unauthorized app inside the device, design flaws in operating system APIs were found, allowing account takeovers across 36 apps with hundreds of millions of installations. Proposes a safer approach.
- "An empirical study of SMS one-time password authentication in Android apps" (2019) — DOI: 10.1145/3359789.3359828 — Text messages were not designed for security. Out of 3,303 popular apps, 544 use text codes, and among them, 536 (98.5%) violate at least one rule derived from the RFC.
- "Understanding the Implications of SIM Card Swap Fraud in India: A Comprehensive Study" (2024) — DOI: 10.1109/ic3iot60841.2024.10550217 — SIM swapping involves attackers persuading telecom operators to transfer a victim's number to the attacker's SIM. By changing passwords tied to that number, they gain access to bank and social media accounts.
- "Mitigating One-Time Passcode (OTP) Fraud: Strengthening authentication against emerging threats" (2025) — DOI: 10.30574/wjarr.2025.26.1.1181 — SIM swapping, man-in-the-middle attacks, social engineering, and telecommunication network vulnerabilities bypass one-time codes. Reviews countermeasures such as multi-factor authentication and FIDO2.
- "A systematic review of multi-factor authentication in digital payment systems: NIST standards alignment and industry implementation analysis" (2025) — DOI: 10.1016/j.sysarc.2025.103402 — Reviewed 70 papers and 13 industry tools. Despite the existence of more advanced methods, 33% of tools rely primarily on one-time codes.
- "Rogue key and impersonation attacks on FIDO2: From theory to practice" (2023) — DOI: 10.1145/3600160.3600174 — Signature-based authentication via USB hardware tokens. Attacks placed out of scope by the design threat model (PIN extraction, impersonation, fake key registration) were easily executed in practice.
- "How Not to Handle Keys: Timing Attacks on FIDO Authenticator Privacy" (2022) — DOI: 10.56553/popets-2022-0129 — The protocol uses challenge-response signing, with a unique key pair per service for privacy. Out of 8 hardware authenticators tested, 2 were vulnerable to account-linking attacks despite being certified, and device-side mitigation is difficult due to unupdatable firmware.
- "Digital Forensic Artifacts of FIDO2 Passkeys in Windows 11" (2024) — DOI: 10.1145/3664476.3664496 — Passkeys create a unique key pair for each website, placing the public key on the website and the private key on an authentication device (the computer itself or a phone). Users authenticate by unlocking the authentication device.
- "FIDO2, CTAP 2.1, and WebAuthn 2: Provable Security and Post-Quantum Instantiation" (2023) — DOI: 10.1109/sp46215.2023.10179454 — FIDO2 is a globally used passwordless authentication standard. Formal security analysis proves quantum resistance under certain conditions and minor extensions.
- "Defeating FIDO2/CTAP2/WebAuthn using browser in the middle and reflected cross site scripting" (2025) — DOI: 10.1007/s11416-025-00556-2 — FIDO2 was previously the only method virtually uncompromisable by any phishing technique, but showed that an attack combined with a reflected XSS vulnerability can defeat all MFA, including hardware dongles.
- "Asynchronous Remote Key Generation" (2020) — DOI: 10.1145/3372297.3417292 — Losing authentication devices prevents access to web services, making a usable recovery method that preserves the original design an urgent need. Analyzes backup authenticator proposals.
- "On the error-reject trade-off in biometric verification systems" (1997) — DOI: 10.1109/34.598237 — Performance evaluation of biometric verification systems. Derives formulas to theoretically calculate false acceptance rates and false rejection rates.
- "Face Liveness Detection Using Artificial Intelligence Techniques: A Systematic Literature Review and Future Directions" (2023) — DOI: 10.3390/bdcc7010037 — Facial recognition is vulnerable to forgeries such as output photo or video playback, and systematically reviews liveness detection research preventing them.
- "Aliveness Detection for IRIS Biometrics" (2006) — DOI: 10.1109/ccst.2006.313440 — Two commercial iris cameras accepted forged irises from output at rates of 73% and 15%. Three proposed methods achieved 0 fake acceptance and 2.8% first-method genuine rejection (0 for the rest) on their own data.
- "Data fusion in biometrics" (2005) — DOI: 10.1109/maes.2005.1396793 — No biometric system guarantees a 100% identification rate or 0% false acceptance/rejection rates. Combining multiple biometric systems is the path to overcoming limits.
- "Guide to Attribute Based Access Control (ABAC) Definition and Considerations" (2014, standard document) — DOI: 10.6028/nist.sp.800-162 — Definition of an access control approach where permissions to perform tasks (authorization) are determined by checking attributes of the subject, object, action, and environment against policies and rules.
- "Design and Analysis of Password-Based Key Derivation Functions" (2005) — DOI: 10.1109/tit.2005.853307 — Password-based methods are subject to dictionary attacks, and in practice, salts and iteration counts greatly increase the workload. Proves the effect of iteration counts and analyzes conditional security of standard methods.
- "FIDO2 y WebAuthn para autenticación organizacional resistente al phishing: revisión sistemática" (2026, systematic review, page quality unknown) — DOI: 10.57166/riqchary/v8.n2.2026.3 — 21 studies. Credentials tied to the site address (origin) reduce interception and relay phishing, but risks of weak recovery, client hijacking, session hijacking, synchronization, and misconfiguration remain. Results are concentrated in Europe and North America.
Sources (35)
- Users are not the enemyDOI 10.1145/322796.322806
- Presentation Attack Detection: A Systematic Literature ReviewDOI 10.1145/3687264
- Unveiling the Covert Vulnerabilities in Multi-Factor Authentication Protocols: A Systematic Review and Security AnalysisDOI 10.1145/3734864
- Online Banking User Authentication Methods: A Systematic Literature ReviewDOI 10.1109/access.2023.3346045
- LinkedIn Password Leak: Salt Their HideDOI 10.1145/2246036.2254400
- Security Analysis of MD5 Algorithm in Password StorageDOI 10.4028/www.scientific.net/amm.347-350.2706
- Security Analysis of salt||password HashesDOI 10.1109/acsat.2012.49
- Quantum-Safe Round-Optimal Password Authentication for Mobile DevicesDOI 10.1109/tdsc.2020.3040776
- Two-Factor Authentication Resilient to Server Compromise Using Mix-Bandwidth DevicesDOI 10.14722/ndss.2014.23167
- Why Do Developers Get Password Storage Wrong?DOI 10.1145/3133956.3134082
- Password management strategies for online accountsDOI 10.1145/1143120.1143127
- Might I Get Pwned: A Second Generation Compromised Credential Checking ServiceDOI 10.48550/arxiv.2109.14490
- Beyond Credential Stuffing: Password Similarity Models Using Neural NetworksDOI 10.1109/sp.2019.00056
- Protocols for Checking Compromised CredentialsDOI 10.1145/3319535.3354229
- The Emperor's New Password Manager: Security Analysis of Web-based Password ManagersDOI 10.21236/ada614474
- A One-Time Password SystemDOI 10.17487/rfc2289
- TOTP: Time-Based One-Time Password AlgorithmDOI 10.17487/rfc6238
- On the Insecurity of SMS One-Time Password Messages against Local Attackers in Modern Mobile DevicesDOI 10.14722/ndss.2021.24212
- An empirical study of SMS one-time password authentication in Android appsDOI 10.1145/3359789.3359828
- Understanding the Implications of SIM Card Swap Fraud in India: A Comprehensive StudyDOI 10.1109/ic3iot60841.2024.10550217
- Mitigating One-Time Passcode (OTP) Fraud: Strengthening authentication against emerging threatsDOI 10.30574/wjarr.2025.26.1.1181
- A systematic review of multi-factor authentication in digital payment systems: NIST standards alignment and industry implementation analysisDOI 10.1016/j.sysarc.2025.103402
- Rogue key and impersonation attacks on FIDO2: From theory to practiceDOI 10.1145/3600160.3600174
- How Not to Handle Keys: Timing Attacks on FIDO Authenticator PrivacyDOI 10.56553/popets-2022-0129
- Digital Forensic Artifacts of FIDO2 Passkeys in Windows 11DOI 10.1145/3664476.3664496
- FIDO2, CTAP 2.1, and WebAuthn 2: Provable Security and Post-Quantum InstantiationDOI 10.1109/sp46215.2023.10179454
- Defeating FIDO2/CTAP2/WebAuthn using browser in the middle and reflected cross site scriptingDOI 10.1007/s11416-025-00556-2
- Asynchronous Remote Key GenerationDOI 10.1145/3372297.3417292
- On the error-reject trade-off in biometric verification systemsDOI 10.1109/34.598237
- Face Liveness Detection Using Artificial Intelligence Techniques: A Systematic Literature Review and Future DirectionsDOI 10.3390/bdcc7010037
- Aliveness Detection for IRIS BiometricsDOI 10.1109/ccst.2006.313440
- Data fusion in biometricsDOI 10.1109/maes.2005.1396793
- Guide to Attribute Based Access Control (ABAC) Definition and ConsiderationsDOI 10.6028/nist.sp.800-162
- Design and Analysis of Password-Based Key Derivation FunctionsDOI 10.1109/tit.2005.853307
- FIDO2 y WebAuthn para autenticación organizacional resistente al phishing: revisión sistemáticaDOI 10.57166/riqchary/v8.n2.2026.3