In recent years, phishing attacks targeting financial institutions and other organisations have become increasingly sophisticated."Real-time phishing"A technique called "phishing" has become a serious threat. This type of attack is known to even invalidate one-time passwords (OTPs), which have traditionally been considered effective in preventing phishing attacks, forcing financial institutions to fundamentally redesign their identity verification infrastructure.
This paper explains the technical structure of real-time phishing and the essential advantages of "passkey," a technology that can counter it, and presents future policy issues for consideration.
What is real-time phishing?
Real-time phishing is an attack method in which an attacker acts as a "man-in-the-middle" between the user and the genuine service, relaying communication and instantly impersonating the user using the authentication information entered by the user (username, password, 4- to 6-digit one-time password (OTP), etc.). In particular, even if the OTP is delivered by SMS or app, the moment the user enters it on the phishing site, the attacker can forward it to the website of the genuine service and log in as the user.
This type of attack is often called man-in-the-middle (MitM), adversary-in-the-middle (AitM) , verifier impersonation Also known as phishing, it is characterized by the fact that it technically relays between a "seemingly genuine" phishing site and a genuine authentication server.
Perfect spoofing by relay servers
Modern real-time phishing attacks use relay servers to trick users with sophisticated schemes, such as:
- Complete site duplication: Reads the source code of a real website (e.g. a financial institution's website) in real time and generates a visually indistinguishable fake website (note that there are also cases where the fake website returns a completely different site when it is called by a testing program, thereby evading testing).
- Obtaining a proper SSL certificate: Serves a legitimate-looking HTTPS connection
- Dynamic content support: Personal information display after logging in is also fully reproduced
How Adversary-in-the-Middle (AitM) attacks work
An AitM attack follows this technical process:
- Relay server installation: Attackers place relay servers between the real site and the user.
- Dynamic Response Generation: The response from the server of the genuine site is altered and sent to the user
- Credential collection: Collect ID, password, OTP and additional personal information in real time
- Execute legitimate access: Instantly access genuine websites using collected information
In this attack, the attacker plays two roles simultaneously:
- For users: Acting like a real bank server (verifier impersonation)
- For banks: Act like a real user
This double impersonation completely invalidates traditional "shared secret"-based authentication methods (passwords, OTP) between the website (authentication server) and the user. Figure 1 shows this relationship.
(Figure 1) Schematic diagram of AitM
Example:
- User enters ID, password and OTP
- The fake site forwards that information to the real authentication server
- Authentication successful, session hijacked
Why OTPs become invalid
OTP (One-Time Password)Code that is difficult to reuseTherefore, it has traditionally been considered a "secure second factor." However, in "relay attacks" such as real-time phishing,If an attacker can use it on behalf of a real user, even if it is just once, the attack will be successful.This invalidates the "disposable" aspect of it.
In addition, traditional OTP-based multi-factor authentication (MFA)Challenge-response integrity verification (see below)or WebVerify the site address (domain)Because it does notUsers cannot tell who their input is going toThis is why OTPs are inherently vulnerable to relay attacks.
What is a passkey?
Passkey is an authentication technology based on the FIDO2/WebAuthn standard.Verify the address (domain) of the website you are accessing and send the information required for user authentication.1The main characteristics are as shown in Figure 2.
(Figure 2) Passkey characteristics
| Features | Description |
|---|---|
| Asymmetric key cryptography | Authentication is performed by signature verification using a public key. The private key is not sent to the recipient. |
| Origin Binding | Authentication requests are tied to a specific domain, making them difficult to relay or spoof (origin check and RPID check - see below). |
| Local authentication with biometrics or PIN | User authentication is completed within the device, with no external transmission of authentication information that could be easily cloned, such as biometric information or PIN. |
| Phishing Resistant | Do not sign requests from fake sites. |
In other words, If a user accidentally accesses a fake site, the authenticator will not return a signature for the real website to that site, so the attacker will not be able to obtain any information to use for authentication.This is a crucial difference from OTP.
Why is Passkey resistant to phishing?
Passkey (FIDO2/WebAuthn)Relay phishing (AitM) and domain spoofingAgainstHas structural resistanceThis is because three checks are performed:
(1) Origin Validation
- The client (browser) issues an authentication request to Website origin (site domain/address)and automatically detect that it is the right site.
- This origin consists of https:// + ドメイン名 + ポート番号 It consists of
- The passkey authentication request from the website to the browser includes the site's domain (RPID, see below), but if this domain is different from the origin (e.g., a phishing site),The browser rejects the authentication request.And no authentication process is performed (there are exceptions such as subdomains)
- In addition, the origin is included in the passkey authentication result and is sent to the web server, so the web server can also verify that passkey authentication was performed on the correct website.
(2) Relying Party ID (RPID) Check
- RPID isThe domain identifier specified by the server when registering the public key
- The authenticator (the device that holds the passkey)Search to see if the key associated with the received RPID is stored in your account
- If the RPID is different, the private key will not be found and the signature will not be returned.
(3) Challenge-Response
- When authenticating with a passkey, the web server sends random data called a "challenge"
- The authenticator uses its private key to sign the data, including the challenge, and returns it to the web server via the browser as a passkey authentication response.
- The web server verifies that the challenge in the response was issued by the web server for that session.
- If the attacker creates an arbitrary challenge or if the challenge has been used before, the web server will reject the challenge.
Why do we need these three?
Figure 3 summarizes this relationship.
(Figure 3) Three elements necessary for phishing resistance
| Item | role |
|---|---|
| Origin Check | The browser detects that the origin toGuaranteed legitimacy. Reject fake sites |
| RPID Check | Confirms if the authenticatorFor which domain the key is registeredto Prevent misuse |
| Challenge-Response | Guarantees that passkey authentication was performed in the current session, preventing reuse of authentication results |
Just one of them is not enough, Only when all of these elements are in place can "complete phishing resistance" be achieved international success.
But passkeys are not a silver bullet
~The risk of phishing attacks exploiting registration flows~
On the other hand, passkeys are not a silver bullet either.Passkey is much more resistant to phishing than traditional OTPs and passwords.It has been highly evaluated as a means to significantly improve the security of user authentication.
However,Resistance to attacks against "credential registration"is dependent on the user's judgment and UX design,An attacker forces a user to "register" their passkeyThere is a new risk.
Possible attack scenario: An attacker “spoofs” a passkey and registers it
Example of attack flow
- An attacker creates a phishing site (https://bank-login.example.org)
- The user is prompted to "Your authentication has expired. Please re-register."
- The user authenticates on the phishing site using traditional authentication methods (password or OTP) and begins the passkey registration flow
- In reality, the attacker's authenticator (device) is registered.
- The attacker's passkey was registered on the real website
- The attacker could then use that passkey to log into the real website.
Technically, it's a "legitimate registration"
- In a relay attack, WebAuthn registration (navigator.credentials.create()) can be performed in the attacker's environment, so the contents can be freely modified by the attacker. Therefore, from the web server's perspective, the registration itself cannot be distinguished from a legitimate one.
- In a relay attack, even if the victim's browser creates a passkey that includes the phishing site's domain as the origin, the attacker can simply discard the result and regenerate a passkey in the attacker's environment that includes the legitimate domain, so checking the origin in the victim's browser is ineffective.
(I.e.
Figure 4 summarizes some representative possible measures, but is not exhaustive.
Figure 4 Possible measures against spoofing
| (I.e. | Message |
|---|---|
| Strengthened identity verification steps before registration | Prevent this by requiring identity verification using public personal authentication or remote biometrics (if possible), or re-authentication using a previously set passkey. |
| Detection and notification of abnormal registration | Instant notification and confirmation when a new passkey is added (e.g. login history notification) |
Possible attack scenario: Session hijacking after passkey authentication
In recent years, there have been reports of theft of passwords and other information using malware collectively known as infostealers. These can also obtain session cookies. A passkey is a protective measure until a session is established after user authentication. It does not provide protection after the session is established.
(I.e.
As a countermeasure against session hijacking, an asymmetric key generated in a secure area of the device is used.Device Bound Session Credentials (DBSC) Also, in this context,Continuous Access Evaluation (Continuous Access Assessment)is also beginning to attract attention.
Continuous Access Evaluation is a security method that goes beyond traditional one-time authentication and continuously monitors and evaluates user access privileges in real time. Even after a user logs in, it constantly checks their location, device status, behavioral patterns, risk level, etc. If it detects abnormal activity or a high-risk situation, it automatically requests additional authentication and restricts or blocks access.
For example, if there is access from a different country than usual or an abnormal data download, you can respond immediately. We discard the premise that "once authenticated, it's safe" and strengthen security by constantly verifying.
Possible attack scenario: Targeting remaining password authentication holes
In order to obtain the benefit of the phishing resistance that is a feature of the passkey, it is necessary to abolish authentication methods that are not phishing resistant and to use only phishing resistant authentication methods such as the passkey. Even if the passkey is introduced, if the conventional user authentication that is not phishing resistant remains, users will still be targeted by phishing.
(I.e.
The corresponding countermeasure would be to eliminate these traditional user authentication methods and switch to passkeys alone.
However, it must be noted that there are still users who find it difficult to use passkeys due to various factors. Forcing a passkey on users in such a situation would be a reason for them to avoid the service. Therefore, while retaining the existing authentication method, it is possible to take alternative measures such as continuing to monitor the session as a high-risk session using AI, and stopping transactions if anomalies are detected. Another option is to provide an option to allow login with a password for a certain period of time (such as 15 minutes) for logins in environments where passkeys cannot be used, or to set transaction limits and permissions (such as read-only) depending on the authentication strength. From this perspective, the above-mentioned Continuous Access Evaluation is attracting attention as an important technology.
Conclusion: If the passkey is not “designed”, it will be cracked.
The passkey isThe authentication process is extremely secureHowever,If the registration flow is exploited, the attacker can register a strong key instead.There is a risk of this being counterproductive.
Therefore, when financial institutions and government agencies implement passkeys:
- Security design for registration flow, not just authentication
- Anomaly detection and recovery flow design
- UX design and warning design based on phishing
Therefore, when adopting a system, it is necessary to take these things into consideration when designing it.
Policy Implications: Why Passkeys Are Needed Now
1. Limitations of regulations and guidelines that rely on OTP
In many countries and regions, multi-factor authentication (MFA) with OTP as the second factor is still specified in the SCA (Secure Customer Authentication) requirements. However, as mentioned above,Multi-factor authentication using OTP does not guarantee phishing resistanceSecurity regulations based on this premise may no longer be keeping up with the technology of attackers. Instead of specifying "two-factor authentication," we should think about which "threats" we should respond to. In fact, the ISO/IEC 2 Entity authentication assurance framework, etc.2It has been that way since.
2. Registration Phase Threats Need to Be Addressed
On the other hand, it is important to keep in mind that the passkey strengthens the authentication method usage phase, so it is also necessary to respond to threats in the authentication method registration phase.
3. Part of defense in depth
Although a passkey is a very effective means of user authentication, it is ineffective for session hijacking after successful user authentication. Therefore, it is necessary to use it in combination with session binding to a device and abnormal transaction detection.
4. Promotion of dissemination from the perspective of consumer protection
The passkey does not require users to have security knowledge or be careful, and ensures security transparently on the terminal side.Sustainable measures that don't rely on security educationThis is highly compatible with consumer protection policies.
From the perspective of monetary policy, it is not enough to simply debate whether or not to introduce technology;What counts as "secure user authentication"It is necessary to update the standards themselves. In the design of future systems,Make phishing-resistant measures like passkeys the "norm"This will be key to ensuring safety and trust for financial consumers.3
[Acknowledgment]
In writing this article, the publisher"All about passkeys"He is also a director of the US OpenID Foundation.Mr. Kosuke Koiwai(X: @kocko), a member of Nomura Research Institute, is the secretary of the Information Processing Society of Japan's Information Standards Research Committee SC27/WG5 subcommittee and is also the liaison officer for the FIDO Alliance to ISO/IEC JTC 1/SC 27/WG 5.Mr. Hideaki Furukawa,Software Design January 2025 issueHe has been proactively posting about passkeys, such as in the first half of "Special Feature 1: The Cutting Edge of Authentication Technology: The Mechanism and Implementation of Passwordless Authentication "Passkey"" in the magazine "Ryo Ito(X: @ritouWe would like to express our sincere gratitude to the person who kindly provided us with such cooperation.
footnote
- In addition, we do not send the "shared secret" to the access destination.
- DIS stage
- As an example, the US government's digital identity guideline, NIST SP800-63-4 2pd, requires the provision of phishing-resistant authentication methods at a person authentication assurance level of AAL2 or higher (users are not required to use them, but it is essential to provide them with the option).