5.3k VIEWS

Facebook Pinterest LinkedIn LINE

In recent years, phishing attacks targeting financial institutions and others have grown increasingly sophisticated. In particular, a method known as “real-time phishing” has become a serious threat. This type of attack is known to defeat even one-time passwords (OTPs), which have traditionally been regarded as an effective phishing countermeasure, forcing financial institutions to fundamentally redesign their identity verification infrastructure.

This article explains the technical structure of real-time phishing and the fundamental advantages of “passkeys,” which can counter it, and presents policy issues for future consideration.

Table of Contents

What Is Real-Time Phishing?

Real-time phishing is an attack in which an attacker relays communications by placing themselves “between the user and the genuine service (man-in-the-middle)” and immediately uses credentials entered by the user (username, password, a 4- to 6-digit one-time password (OTP), etc.) to impersonate that user. In particular, even when an OTP is delivered by SMS or an app, the moment the user enters it on a phishing site, the attacker can forward it to the genuine service’s website and log in while impersonating the user.

This kind of attack is also called man-in-the-middle (MitM), adversary-in-the-middle (AitM), or verifier impersonation. Its defining characteristic is the technical relaying of communications between a phishing site that “appears genuine at first glance” and the genuine authentication server.

Complete Deception Using a Relay Server

Modern real-time phishing attacks use relay servers to deceive users through sophisticated techniques such as the following:

Complete site cloning: The source code of a genuine website (for example, a financial institution’s website) is loaded in real time to generate a fake site that is visually indistinguishable. Some examples also evade inspection by returning entirely different content when an inspection program visits.
Obtaining a plausible SSL certificate: Provides an HTTPS connection that appears legitimate.
Support for dynamic content: Fully reproduces even the display of personal information after login.

How an Adversary-in-the-Middle (AitM) Attack Works

An AitM attack is carried out through the following technical process:

Relay server installation: The attacker places a relay server between the genuine site and the user.
Dynamic response generation: Responses from the genuine site’s server are altered and sent to the user.
Credential collection: IDs, passwords, OTPs, and additional personal information are collected in real time.
Legitimate access: The collected information is used to access the genuine website immediately.

In this attack, the attacker simultaneously plays the following 2 roles:

Toward the user: Behaves like the genuine bank server (verifier impersonation).
Toward the bank: Behaves like the genuine user.

This dual impersonation completely defeats conventional “shared secret”-based authentication methods (passwords and OTPs) between the website (authentication server) and the user. Figure 1 illustrates this relationship.

(Figure 1) Schematic of AitM

Example:

The user enters an ID, password, and OTP.
The fake site forwards that information to the genuine authentication server.
Authentication succeeds, and the session is hijacked.

Why OTPs Become Ineffective

An OTP (one-time password) has traditionally been regarded as a “secure second factor” because it is a code that is difficult to reuse. In a “relay attack” such as real-time phishing, however, the attack succeeds if the attacker can use the code in place of the genuine user, even if it can be used only once. Its disposable nature is therefore rendered ineffective.

Furthermore, conventional OTP-based multifactor authentication (MFA) performs neither challenge-response integrity verification (discussed below) nor verification of the Website address (domain), among other things. Consequently, the user cannot determine to whom the entered information is about to be sent. This is why OTPs are inherently vulnerable to relay attacks.

What Is a Passkey?

A passkey is an authentication technology based on the FIDO2/WebAuthn standards. It has the property of verifying the address (domain) of the website being accessed and sending the information required for user authentication¹ Its main characteristics are shown in Figure 2.

(Figure 2) Characteristics of Passkeys

Characteristic	Description
Based on asymmetric-key cryptography	Authentication is performed by verifying a signature with a public key. The private key is not sent to the destination.
Origin binding	Authentication requests are tied to a specific domain, making relaying and impersonation difficult. (See the origin check and RPID check below.)
Local authentication using biometrics or a PIN	User authentication is completed within the device. No authentication information using potentially replicable factors, such as biometric information or a PIN, is sent externally.
Phishing resistance	Requests from fake sites are not signed.

In other words, even if the user mistakenly visits a fake site, the authenticator does not return a signature for the genuine website to that site, so the attacker cannot obtain any information that can be used for authentication. This is the decisive difference from an OTP.

Why Are Passkeys Resistant to Phishing?

Passkeys (FIDO2/WebAuthn) have structural resistance to relay phishing (AitM) and domain impersonation because the following 3 checks are performed:

(1) Origin Check (Origin Validation)

The client (browser) automatically detects the origin (site domain/address) of the Web site issuing the authentication request
This origin consists of https:// + domain name + port number.
A passkey authentication request from a website to a browser includes the site’s domain (RPID, discussed below). If this domain differs from the origin (for example, a phishing site), the browser rejects the authentication request and authentication does not occur (with exceptions such as subdomains).
Moreover, because the origin is included in the passkey authentication result and sent to the Web server, the Web server also verifies that passkey authentication was performed on the correct website.

(2) Relying Party ID (RPID) Check

An RPID is a domain identifier specified by the server when the public key is registered
The authenticator (the device holding the passkey) searches to determine whether it has a stored key associated with the received RPID
If the RPID differs, the private key is not found and no signature is returned

(3) Challenge-Response

During passkey authentication, the Web server sends random data called a “challenge.”
The authenticator signs data containing the challenge with the private key and returns it to the Web server through the browser as the passkey authentication response.
The Web server verifies that the challenge contained in the response is the one that the Web server issued for that session.
If the challenge was arbitrarily created by an attacker or has been used in the past, the Web server rejects authentication.

Why Are These 3 Checks Necessary?

Figure 3 summarizes this relationship.

(Figure 3) The 3 Elements Required for Phishing Resistance

Item	Role
Origin check	The browser ensures the legitimacy of the website executing the request and rejects fake sites.
RPID check	The authenticator checks the domain for which the key was registered and prevents misuse.
Challenge-response	Ensures that passkey authentication was performed in the current session and prevents reuse of the authentication result.

Any 1 of them alone is insufficient; “complete phishing resistance” is achieved only when all are present.

However, Passkeys Are Not a Silver Bullet

—The Risk of Phishing Attacks That Exploit the Registration Flow—

Passkeys are not a silver bullet, either. FIDO2/WebAuthn-based passkeys have dramatically greater phishing resistance than conventional OTPs and passwords and are recognized as a means of substantially improving the security of user authentication.

However, resistance to attacks on the “credential registration” flow partly depends on user judgment and UX design, creating a new risk: an attacker may cause their own passkey to be “registered”.

Potential Attack Scenario: Fraudulent Registration of an Attacker’s Passkey

Example Attack Flow

The attacker builds a phishing site (https://bank-login.example.org）
The user is prompted with a message such as, “Your authentication has expired. Please register again.”
The user authenticates on the phishing site using a conventional authentication method (password or OTP) and starts the passkey registration flow.
In reality, the attacker’s authenticator (device) is registered.
The genuine website is left with the “attacker’s passkey” registered.
The attacker can then use that passkey to log in to the genuine website.

Technically, It Is a “Legitimate Registration”

In a relay attack, WebAuthn registration (navigator.credentials.create()) can be performed in the attacker’s environment, allowing the attacker to alter its contents freely. From the Web server’s perspective, therefore, the registration itself cannot be distinguished from a legitimate one.
In a relay attack, even if the victim’s browser creates a passkey with the phishing site’s domain as the origin, the attacker can discard that result and generate another passkey in the attacker’s environment using the legitimate domain. The origin check in the victim’s browser is therefore ineffective.

Countermeasures

Figure 4 summarizes representative potential countermeasures. It is not exhaustive.

Figure 4 Potential Countermeasures Against Impersonation

Countermeasure	Details
Strengthen identity verification before registration	Prevent attacks by requiring identity verification using public personal authentication or remote biometrics (where possible), or reauthentication with a previously configured passkey.
Detect and notify about anomalous registrations	Provide immediate notification and confirmation when a new passkey is added (for example, a login-history notification).

Potential Attack Scenario: Session Hijacking After Passkey Authentication

Recent cases have also reported the theft of passwords and other data by malware collectively known as infostealers. Such malware can likewise obtain session cookies. Passkeys protect the process from user authentication until a session is established. They do not protect the session after it has been established.

Countermeasures

Measures proposed against session hijacking include Device Bound Session Credentials (DBSC), which use asymmetric keys generated in a secure area of the device. In this context, Continuous Access Evaluation (continuous access evaluation) has also begun to attract attention.

Continuous Access Evaluation is a security technique that goes beyond conventional one-time authentication to continuously monitor and evaluate a user’s access privileges in real time. Even after the user logs in, it continually checks location information, device status, behavioral patterns, risk level, and other factors. When anomalous activity or a high-risk situation is detected, it automatically requests additional authentication or restricts or blocks access.

For example, it can respond immediately to access from an unusual country or anomalous data-download activity. Security is strengthened by abandoning the assumption that “authentication once means safety” and instead continuing to verify at all times.

Potential Attack Scenario: Targeting Remaining Password-Authentication Entry Points

To gain the benefit of phishing resistance, a defining characteristic of passkeys, authentication methods without phishing resistance must be retired and users must use only phishing-resistant authentication methods such as passkeys. Even if passkeys are introduced, users remain phishing targets if conventional user-authentication methods without phishing resistance remain available.

Countermeasures

The corresponding measure is to retire these legacy user-authentication methods and switch entirely to passkeys.
However, it must be recognized that various factors leave some users unable to use passkeys easily. Forcing passkeys under those circumstances can give users a reason to avoid the service. An alternative may therefore be to retain existing authentication methods while treating such sessions as high-risk sessions, continuously monitoring them with AI or other means, and stopping transactions when anomalies are detected. Other options include permitting password login only for a limited period (such as 15 minutes) for login from environments where passkeys cannot be used, or setting transaction limits and permissions (such as read-only access) according to authentication strength. From this perspective as well, Continuous Access Evaluation is attracting attention as an important technology.

Conclusion: Passkeys Can Be Defeated Without Proper “Design”

Passkeys provide extremely high security in the authentication flow, but if the registration flow is exploited, the attacker may instead register a strong key, creating a counterproductive risk.

Therefore, when financial institutions or government agencies introduce passkeys, the following are essential:

Security design for the registration flow, not only authentication
Anomaly detection and recovery-flow design
UX and warning design that assumes phishing will occur

These elements are indispensable. They must therefore be considered and designed for when passkeys are adopted.

Policy Implications: Why Passkeys Are Needed Now

1. Limitations of Regulations and Guidelines That Depend on OTPs

In many countries and regions, OTPs may still be expressly specified as a second factor for multifactor authentication (MFA) under SCA (Secure Customer Authentication) requirements. As explained above, however, multifactor authentication using an OTP does not guarantee phishing resistance. Security regulations based on that assumption may already have fallen behind attackers’ technology. Instead of specifying “2-factor authentication,” consideration should focus on which “threats” must be addressed. Indeed, ISO/IEC 29115 Entity authentication assurance framework has taken this approach since the 2011 ².

2. The Need to Address Threats in the Registration Phase

It must also be noted that passkeys strengthen the phase in which an authentication method is used. Threats in the phase in which authentication methods are registered must also be addressed.

3. Part of Defense in Depth

Passkeys are a highly effective user-authentication method, but they are ineffective against session hijacking after user authentication succeeds. They must therefore be used in combination with measures such as binding sessions to devices and detecting anomalous transactions.

4. Promoting Adoption from the Perspective of Consumer Protection

Passkeys do not require users to have “security knowledge” or be “careful”; instead, the device transparently ensures security. This is a sustainable countermeasure that does not rely on security education and is highly compatible with consumer-protection policy.

From a financial-policy perspective, it is necessary not only to debate whether a technology can be introduced but also to update the very criteria for what is considered “secure user authentication”. In future institutional design, establishing phishing-resistant methods such as passkeys as the “standard” will be key to ensuring the safety of financial consumers and maintaining trust.³

Acknowledgments

In writing this article, we received tremendous assistance from Kosuke Koiwai, a coauthor of the Gijutsu-Hyoron Co., Ltd. publication “All About Passkeys” and a director of the U.S.-based OpenID Foundation, Kosuke Koiwai (X: @kocko); Hideaki Furukawa of Nomura Research Institute, secretary of the Information Processing Society of Japan’s Information Standards Research Committee SC27/WG5 subcommittee and liaison officer from the FIDO Alliance to ISO/IEC JTC 1/SC 27/WG 5; and Ryo Ito, who actively shares information about passkeys, including in the first half of “Software Design, January 2025 Issue,” Special Feature 1, “The Forefront of Authentication Technology—How Passwordless Authentication ‘Passkeys’ Work and Are Implemented,” Ryo Ito (X: @ritou). We extend our deepest gratitude to them.

Footnotes

It does not send a “shared secret” to the destination.
DIS stage
As one example, NIST SP 800-63-4 2pd, the U.S. government’s Digital Identity Guidelines, requires that phishing-resistant authentication methods be made available at authenticator assurance level AAL2 or higher (users are not required to use them, but must be offered the option).