Mercari, Inc. offers C2C marketplace services as well as online and mobile payment solutions. Users can sell items on the marketplace, and make purchases in physical stores.
Mercari is actively working on preventing phishing attacks. This is the driving force behind the adoption of passkey authentication. To enhance phishing resistance, several factors need to be considered, leading to the introduction of a few requirements:
1) SMS OTP is required to register the first passkey.
2) Passkey authentication is required to register the second passkey.
3) The authentication should be via hybrid transport.
This article will discuss the motivations behind this decision, the challenges faced, and how they were addressed.
Motivation
There were primarily two motivations for adopting passkey authentication. The first was to mitigate real-time phishing attacks. When several phishing sites targeted users of Mercari in 2021 Mercari adopted SMS OTP (One-Time Password) as an additional form of authentication as a countermeasure of these attacks. This strategy proved effective as it required attackers to obtain the SMS OTP multiple times, which is difficult to achieve by a real-time phishing site. However, repeatedly sending SMS OTPs was both expensive and not user-friendly, and it couldn’t entirely prevent account takeovers. Transitioning to passkey authentication allowed us to reduce the cost associated with SMS OTPs while also improving the user experience.
The second motivation stemmed from the requirement for a new service: Mercoin, which is a platform for buying and selling Bitcoin with the user’s available balance in Mercari. Given that this service deals with cryptocurrency assets, it was clear that the service required stronger security measures than ordinary services. We already knew that our existing authentication methods, using passwords and SMS OTPs were not sufficient in protecting our services and users from real-time phishing attacks. By implementing passkey authentication, we were able to better protect our features and users from real-time phishing attacks.
Mercari’s Current Authentication Situation
Mercari supports various authentication methods including passwords, SMS OTPs, social logins, and passkeys. These authentication methods are used for specific operations such as signing into a Mercari account, initiating critical operations such as transfering money out of Mercari, or accessing Mercoin. Each operation requires a different combination of authentication methods. For instance, logging into a Mercari account requires two-factor authentication, such as a password coupled with an SMS OTP, or a social login plus an SMS OTP.
Using Mercoin requires passkey authentication, both for accessing Mercoin’s main features and initiating critical operations. This cannot be substituted by any other authentication methods because we want to make these Mercoin features phishing-resistant.
Recently, passkey authentication has also become available for Mercari’s critical operations, such as changing passwords or transferring money out of Mercari. It serves as an additional layer of authentication, instead of relying solely on SMS OTP.
As of this writing, over 900,000 Mercari accounts have registered passkeys. The success rate and median of authentication time are as follows. The higher the success rate of authentication and the shorter the authentication time, the better the user experience is. This is especially important when requiring users to use extra authentication methods, as requiring this additional action is an obstacle for the users who want to accomplish something else using the app. In these situations the success rate and authentication time has a significant impact on the user.
| Success rate | Authentication time | |
|---|---|---|
| SMS OTP | 67.7% | 17 s |
| Passkey | 82.5% | 4.4 s |
Making a phishing-resistant environment
The implementations of the passkey in Mercari and in Mercoin serve different purposes. In Mercari’s critical operations, the purpose is to enhance the user experience, while in Mercoin, it aims to improve security, in other words, creating a phishing-resistant environment. Achieving this involves multiple challenges which include requiring authentication with a passkey, requiring the strongest authentication for passkey management, and implementing a proper proximity boundary.
Require the strongest authentication for passkey management
The strongest authentication for a user is the strongest possible means of authenticating that user (possibly combining multiple authentication methods), based on the authentication methods available to their account. For example, if a user has already registered to use a passkey, then passkey authentication would be their strongest authentication. However, if the user has not registered a passkey, then their strongest authentication would be the combination of password authentication and SMS OTP.
This becomes important when considering the authentication mechanism required when a user wants to bind a passkey to their existing Mercari account. Consider the following attack scenario:
- Attacker obtains a victim’s account through a phishing site.
- Attacker registers a passkey to the account using the attacker’s own device.
- Attacker uses this passkey to exploit the Mercoin feature.
To mitigate this type of attack, the binding between a passkey and an existing Mercari account must be protected using the strongest possible authentication methods.
In other words, passkey management operations such as adding new passkeys or deleting existing ones must be treated as critical procedures and be protected with additional authentication.
This means that a user would be required to use SMS OTP for the first passkey registration, while passkey authentication would be required for subsequent passkey registrations.
Using this approach an attacker who obtains a victim’s information through a phishing site would still need to authenticate with the existing passkey to register a new one to obtain access to our services, which would be difficult to perform. Unfortunately if the user’s account has not yet set up a passkey, the attacker would be able to register a passkey because the required authentication method, SMS OTP, is not phishing resistant. This vulnerability is unavoidable. However, at the very least, high-value accounts can still be protected.
Proper proximity boundary
Careful consideration is needed for implementing passkey authentication as an additional authentication. Users can be required to use a different device to authenticate from the one they are using to access the service, for example when adding a new passkey for the first time on the device the user is using. The establishment of a proximity boundary plays a crucial role in creating a phishing-resistant environment.
The proximity boundary refers to the limitation on the proximity between the device requesting registration and the device receiving the authentication request. If there are no restrictions, it could potentially lead to vulnerabilities against phishing attacks. For instance, if passkey authentication is requested to issue an OTP or via push notification for registering a new passkey, the following attack scenario becomes a concern:
- An attacker obtains a victim’s account through a phishing site.
- The attacker initiates the passkey registration process and follows the instructions appearing on their device.
- The attacker issues instructions to the victim via the phishing site to obtain information to satisfy the instructions from step 2. For instance:
a. Input an OTP into the phishing site. This OTP can be issued using passkey authentication on the victim’s device.
b. Input an OTP displayed on the phishing site into the victim’s device to authorize the enabling of an additional requested passkey.
c. Authenticate with a passkey on the victim’s device. - The attacker can then proceed with the passkey registration if the victim follows these instructions.
To mitigate this kind of attack, it is necessary to make the proximity boundary between the device requesting registration and the device receiving the authentication request.
Several potential methods exist for making the proximity boundary, such as using geo-location or IP addresses. However, these may not always be accurate. We can also use hybrid transport to make the proximity boundary, which Mercari’s passkey management relies on. Hybrid transport can serve as an alternative option when the user cannot use a passkey on a device because it requires connection to a hybrid client and hybrid authenticator via Bluetooth.
In such a situation, even if an attacker obtains a victim’s account via a phishing site and attempts to complete the passkey registration process, passkey authentication within the appropriate proximity boundaries would be required if the account uses Mercoin.
Remaining challenges
Concerns of UX on passkey bindings
Based on the above, we can identify a few requirements to make a phishing-resistant environment:
- SMS OTP is required to register the first passkey.
- Passkey authentication is required to register the second passkey.
- This authentication should occur via hybrid transport.
These restrictions would become sticking points to some users.
First, the need for additional authentication to manage passkey registration can be perceived as cumbersome. If users register a synced passkey, they are unlikely to confront this situation frequently. However, for users with a device-bound passkey or those using multiple platform devices, they will have to register a different passkey with additional authentication. There may not become a problem as long as the authentication process is smooth, but otherwise some users may find the procedure frustrating.
The second potential problem lies in the user experience with hybrid transports. Particularly, current Android devices do not yet support hybrid clients, even though they support hybrid authenticators. This means that users cannot initiate the passkey registration from an Android device if the account has already registered a passkey with, for instance, an iOS device. There is a way to register a passkey on an Android device from an iOS device using hybrid transport, but it’s quite complicated.
Additionally, the user experience when a user cannot access a passkey on the device directly is complicated and varies between operating systems. If Relying Party (RP) uses iOS’s native API to access the passkey, a QR code can be displayed to initiate hybrid transport. This is straightforward. However, if RP uses Android’s native API or WebAuthn, users can select other methods. For example, the user could specify a separate device to use for the procedure. This increases the options available, but it also increases what the user needs to understand and select.
The third point is the recovery procedure when users lose their passkey. Given the aforementioned requirements, if users lose the capability to access all of their registered passkeys, they cannot recover by themselves. In such a scenario, users have to request customer support to reset their passkey registration to their initial state and then register a new passkey as the first passkey. When users encounter this situation, they must wait for a response from customer support, and this waiting period can lead to frustration.
—
If Android devices get support for hybrid clients, it could address the second point above. However, other points would still remain. To further improve the system, we would need to consider ways to bypass additional authentication based on some form of risk verification.
Is synced passkey acceptable for Mercari?
There is yet another potential attack scenario involving the use of passkeys.
- The attacker obtains the victim’s passkey provider’s account via a phishing site.
- The attacker also acquires a secret that allows them to share the passkey with their device.
- They then exploit the Mercoin feature using this obtained passkey.
The synced passkey is shared between devices on the same platform. So, if a malicious attacker obtains credentials to access the passkey provider, they can use the passkey shared through the provider. This forms a new threat associated with synced passkeys.
This scenario is not critical for Mecari at the time of writing, because passkey authentication does not apply to Mercari login process. Mercoin features necessitate the use of two distinct authentication methods, each of which is managed by separate entities: password + SMS OTP managed by Mercari, and passkey managed by the passkey provider. Therefore, even if a passkey leaks from the passkey provider, it is not critical at present.
However, in the near future, we aim to adopt passkey authentication for the Mercari login process as well. In this scenario, such an attack can become critical because if an attacker gains access to the passkey provider, they can access all Mercari and Mercoin features with the passkey.
The only way to manage this situation is by defining a trust boundary and requiring additional authentication for untrusted authentication requests. The key point here is that the authentication method used for additional authentication must be managed by the RP.
Several potential options to define the trust boundary are being considered today, such as DPK, Certification, and Attestation – however, most of the options are currently unavailable. The selection must be made based on each RP’s security requirements and the approach to validating the risk of this attack. Mercari will also need to make a decision before introducing passkey authentication for the login procedure.
Conclusion
Mercari is actively working on preventing phishing attacks. This is the driving force behind the adoption of passkey authentication. To enhance phishing resistance, several factors need to be considered, leading to the introduction of a few requirements:
1) SMS OTP is required to register the first passkey.
2) Passkey authentication is required to register the second passkey.
3) The authentication should be via hybrid transport.
While these measures increase the feature’s security, they also result in some user friction. Efforts are ongoing to refine this process and make it more user-friendly.
