Forem: Oliver

Implementation of Third-Party User Interaction Based on Instant Messaging System

Oliver — Fri, 03 Apr 2026 09:12:02 +0000

Nowadays, many types of third-party apps such as games, shopping, travel, and enterprise applications have the need for communication between users within the app. Currently, there are two main methods, but both have obvious flaws:

First, the third-party app itself develops and provides in-app messaging services.
However, message interaction is not the core business of such apps; developing and maintaining a messaging system independently will significantly increase the cost for developers. At the same time, most third-party apps have low user usage frequency, and users do not log in frequently, leading to messages often failing to be received and viewed in a timely manner, which affects interaction efficiency.

Second, users actively leave their instant messaging accounts or QR codes on third-party apps, allowing other users to jump to instant messaging tools for communication.
Although this method can solve the problem of timely message delivery, both parties cannot directly identify each other's real identities in the third-party app within the instant messaging tool. They can only confirm each other's identities in the app through manual explanation, which is not only cumbersome to operate but also lacks reliability, making it easy to have identity impersonation and misidentification.

To solve the above pain points, this paper proposes a technical concept for realizing third-party user interaction based on an instant messaging system, enabling users to communicate timely through commonly used instant messaging tools (such as WhatsApp, Telegram, Messenger, WeChat, Viber) while automatically identifying each other's identities in the third-party app, achieving a balance of security, efficiency and convenience.

I. Specific Implementation Process

1. User Initiates Instant Messaging Operation
The user initiates a request to send a message, establish a conversation, or add a friend to the instant messaging server through the instant messaging client, and clearly specifies that the operation is associated with a certain third-party app. The identifier of the third-party app can be automatically imported through the app link jump, without the need for manual input by the user.
2. Instant Messaging Server Identifies Objects and Associated Applications
After receiving the user's request, the instant messaging server automatically completes two identification tasks: first, determining the sender and receiver of the current instant messaging operation; second, clarifying the third-party app corresponding to the request, realizing the association between the instant messaging operation and the third-party application.
3. Instant Messaging Server Obtains and Displays Third-Party App Identity Information
The instant messaging server binds the user's instant messaging account with the corresponding third-party app account through an account association mechanism, then automatically obtains the sender's identity information (such as user nickname, avatar, etc.) in the third-party app, and synchronously sends this information to the receiver.
In the instant messaging chat interface, the receiver can directly and clearly see which third-party app the other party is from and the other party's specific identity in the app, without the need for additional inquiries or confirmation.
At the same time, the instant messaging server can also synchronously send the receiver's identity information in the third-party app to the sender, realizing two-way identity recognition between both parties; in addition, it can also synchronously display basic information such as the name and icon of the third-party app, further avoiding identity confusion and improving the interaction experience.

II. Advantages of the Scheme

1. Reduce the development cost of third-party apps: Third-party apps do not need to develop and maintain their own message interaction systems, and can directly rely on the existing instant messaging system to realize user interaction, greatly saving development, operation and server resources.
2. More timely message delivery: With the help of high-user-activity and high-frequency instant messaging tools such as WhatsApp, messages can reach users quickly, completely solving the problem of delayed reception of in-app messages in third-party apps.
3. Real and identifiable identity: There is no need for users to manually note or prove their identities. The system automatically synchronizes and displays the real identity information in the third-party app, effectively avoiding problems such as identity impersonation and misidentification, and improving the security and credibility of interaction.
4. Simple and convenient to use: Users can initiate chats and add friends with one click, without manually copying accounts or scanning QR codes, simplifying the operation process and greatly improving the user interaction experience.

In summary, this scheme enables user interaction of third-party apps to not only leverage the advantages of high reach and high activity of instant messaging tools but also realize clear recognition of cross-platform identities. While significantly reducing the development and operation costs of third-party apps, it effectively improves the security, timeliness and convenience of user interaction.

Security Risks of OTP Fallback Strategies Triggered by Modified WhatsApp Clients

Oliver — Mon, 02 Feb 2026 07:42:50 +0000

In identity verification scenarios, One-Time Passwords (OTPs) serve as a core technical mechanism for securing user accounts and confirming user identity. They are widely used in critical business processes such as account registration, login authentication, sensitive operation confirmation, and transaction authorization. By leveraging characteristics such as short validity periods and single-use constraints, OTPs effectively reduce the risk of credential reuse or long-term abuse, making them an indispensable security component in modern internet services.

To further improve OTP delivery rates and verification success rates, mainstream Verify API products—such as Twilio Verify API, Telesign Verify API, and Bird Verify API—have widely adopted OTP fallback strategies. A typical implementation follows this approach:
an OTP is first delivered to the target user via a WhatsApp OTP template message; when the WhatsApp channel is determined to have failed, the system automatically switches to the SMS channel and resends the same OTP, thereby balancing delivery efficiency with channel compatibility.

Under normal circumstances, this strategy effectively reduces verification failures caused by single-channel unavailability and significantly improves overall verification success rates. However, when target users are using third-party modified WhatsApp clients—such as GBWhatsApp or FWWhatsApp—the existing OTP fallback mechanism may be disrupted. This disruption can lead to a series of security risks and operational anomalies, reducing the predictability of the verification process and potentially harming user interests as well as the security compliance of Verify API services.

I. OTP Fallback Mechanism and WhatsApp Delivery Status Feedback

To understand the root cause of these risks, it is first necessary to clarify the core logic of OTP fallback mechanisms employed by mainstream Verify API products in WhatsApp-based scenarios.

Under normal conditions, after a Verify API server submits a request to the WhatsApp server to send an OTP template message, the WhatsApp server delivers the message to the target user’s official WhatsApp client. Once the official WhatsApp client successfully receives the message, it returns delivery status receipts—such as “Delivered”—to the WhatsApp server in accordance with the protocol specifications.

These delivery receipts are then synchronized back to the Verify API server. Upon confirming that the OTP has been successfully delivered, the Verify API server terminates the fallback workflow and does not trigger OTP delivery via the SMS channel.

Conversely, when one of the following conditions occurs:

The WhatsApp channel times out
The user device is offline or fails to receive the message for an extended period
The client does not return valid delivery status receipts
The channel is deemed unavailable

the Verify API server fails to receive a valid “Delivered” receipt within a predefined time window. In such cases, the server executes the fallback strategy and resends the same OTP to the user via the SMS channel, ensuring that the user can still obtain the OTP and complete identity verification.

II. Protocol Behavior Differences in Modified WhatsApp Clients

Modified WhatsApp clients such as GBWhatsApp and FWWhatsApp are typically created through reverse engineering, functional modification, and repackaging of the official WhatsApp APK. While these clients retain basic messaging capabilities, they introduce varying degrees of modification to protocol implementations, delivery receipt mechanisms, and client-side behavior control logic.

Specifically, with respect to message status feedback, modified WhatsApp clients may:

Suppress sending “Delivered” or “Read” receipts to the server
Delay, restrict, or selectively block delivery receipt reporting
Interfere with the synchronization of message status between the client and the server

These behavioral differences directly undermine the “delivery-status-aware” design assumption upon which OTP fallback strategies rely, and they constitute the fundamental cause of the associated security risks.

III. Major Security Risks Introduced by Modified WhatsApp Clients
(1) Risk of Duplicate OTP Delivery and Multiple Exposure

In official WhatsApp clients, OTP delivery status is accurately reported back to the Verify API server, enabling the server to determine whether fallback delivery is required. However, in modified WhatsApp clients such as GBWhatsApp and FWWhatsApp, even if the user has successfully received the OTP, the absence of valid delivery receipts causes the Verify API server to determine—based on predefined logic—that the WhatsApp channel has failed, thereby triggering SMS fallback delivery.

As a result:

The same OTP is first sent via the WhatsApp channel
The same OTP is subsequently resent via the SMS channel
The OTP is duplicated and exposed across multiple channels

The increased exposure frequency significantly raises the risk of OTP interception, forwarding, or abuse, thereby weakening the intended “short-lived, single-use, secure” design principle of OTP-based authentication.

(2) Risk of Compromising Verify API Backend Security Auditing

OTP delivery and verification processes are typically critical components of the Verify API backend security auditing system. Audit functionality must accurately record each OTP’s delivery channel, timestamp, delivery status, and verification outcome to support risk analysis, anomaly investigation, and compliance audits.

In dual-delivery scenarios triggered by modified WhatsApp clients, backend audit records may indicate:

WhatsApp channel delivery failure
Successful delivery via the SMS channel

However, the actual situation may be that the user has already received the OTP through the modified WhatsApp client.

Such inconsistencies between audit records and real user behavior can lead to:

Significantly increased difficulty in risk attribution
Inability to accurately reconstruct abnormal verification events
Unreliable conclusions in security incident investigations
Audit results that fail to adequately support compliance reviews and accountability requirements

From the service provider’s perspective, such audit distortion weakens overall risk control capabilities and introduces compliance uncertainties.

(3) Risk of Preemptive Verification and Account Security Compromise

In more severe scenarios, if a device running a modified WhatsApp client is not under the legitimate account holder’s control—for example, if it is compromised by malware or subject to monitoring—an attacker may exploit it to perform preemptive verification attacks.

Specifically, a malicious modified WhatsApp client may automatically extract the OTP upon receipt and submit a verification request to the Verify API server before the SMS fallback message is delivered. Because both WhatsApp and SMS channels use the same OTP, once the first verification request succeeds, the OTP immediately becomes invalid.

Subsequently, when the legitimate user receives the same OTP via SMS and attempts verification without being aware of the prior misuse, the verification fails due to OTP expiration. This not only degrades the user experience but may also conceal the fact that the account has already been illicitly verified or logged into, thereby further amplifying account security risks.

Overall, modifications to delivery status feedback mechanisms in modified WhatsApp clients disrupt the fundamental design logic of mainstream OTP fallback strategies. This disruption leads to a cascade of risks, including duplicate OTP exposure, audit data distortion, user verification failures, and compromised account security.

IV. Root Cause Analysis

In summary, interference by modified WhatsApp clients with message delivery status feedback directly undermines the core design principle of OTP fallback strategies—namely, making fallback decisions based on reliable delivery status signals. This results in:

Multi-channel duplicate OTP exposure
Distorted security audit data
User verification failures and degraded user experience
Increased risk of preemptive OTP verification attacks

These issues not only threaten user interests but also impose significant security and compliance pressure on Verify API service providers. Moreover, as Verify APIs are themselves foundational security services, their design must ensure a high level of intrinsic security and compliance.

V. Mitigation Recommendations

To address the above risks, a simple yet effective improvement is recommended:

When OTP delivery via the WhatsApp channel is deemed to have failed and SMS fallback is triggered, the system should generate a new OTP instead of resending the same OTP via SMS.

This approach provides the following benefits:

Different channels use different OTPs, eliminating multiple exposures of the same OTP
Audit records accurately reflect actual delivery and receipt scenarios, ensuring reliable audit data
Suppression of delivery receipts by modified WhatsApp clients does not affect the independent security of SMS-delivered OTPs
Preemptive verification attacks no longer cause SMS-based verification failures

By removing reliance on WhatsApp client trustworthiness, this approach significantly strengthens the security boundary of OTP fallback mechanisms. It is well suited to today’s complex and heterogeneous client environments and can be implemented with minimal changes to existing fallback architectures and low development cost.

Unified Authentication and Key Distribution Scheme for Apps Without Human-Device Interaction

Oliver — Wed, 15 Oct 2025 03:42:43 +0000

Overview
For mobile applications (Apps, i.e., client-side applications) deployed on smart devices, establishing a unified identity authentication and key distribution mechanism during interactions with their corresponding application servers can help users avoid repeated registration processes, thereby optimizing user experience. At the same time, such a mechanism can significantly reduce development and management costs while fostering the growth of an open API ecosystem.
From the platform provider’s perspective, offering a unified authentication solution to third-party applications is of critical importance. From both a system architecture design and security governance standpoint, a unified authentication solution is not only a key mechanism to ensure secure interactions between the platform and third-party applications, but also a foundational pillar in building an open API ecosystem.
However, existing widely adopted frameworks such as OAuth 2.0, as well as conventional key agreement and distribution schemes, exhibit inherent limitations.

Existing Solutions and Limitations
OAuth 2.0 Framework
OAuth 2.0 is currently the most widely used authorization framework, designed to address the problem of secure access to user resources by third-party applications (e.g., social login, API calls). By defining standardized flows, it enables secure interactions among the user (resource owner), the client (third-party application), and the authorization server.
Typical use cases of OAuth 2.0 include third-party login (identity authentication), such as logging into apps using WeChat, Alipay, or Weibo accounts; as well as secure API access, such as invoking Google APIs.
Smartphone manufacturers such as Huawei and Samsung also support OAuth 2.0, applying it to various typical use cases while optimizing the authorization flow for mobile environments. For example, Huawei’s OAuth 2.0 service supports both:

Official Huawei apps (deep integration), widely used within the Huawei ecosystem (e.g., Huawei Cloud, Game Center, App Market, Video, Music).
Third-party apps (non-Huawei developers), allowing developers to integrate Huawei account login and access Huawei ecosystem APIs (e.g., Taobao, Xiaohongshu). However, the OAuth 2.0 framework has several notable drawbacks and limitations:
User Experience Impact: In the commonly used authorization code flow, users must be prompted with an authorization screen to confirm consent, which interrupts the user experience.
Device Constraints: It is unsuitable for smart devices without human-device interaction (e.g., IoT devices, smart TVs), and does not support machine-to-machine (M2M) scenarios.
Risk of Data Leakage in Transmission: Authorization codes and access tokens are exposed to risks during transmission and heavily rely on SSL for protection.
Local Storage Risks: Tokens stored on smart devices face security vulnerabilities.
Complex Token Exchange: Third-party servers must exchange authorization codes for access and refresh tokens, complicating implementation.
No Built-in Encryption: Token transmission relies entirely on HTTPS; the framework itself does not provide intrinsic encryption.

Key Agreement Protocols
Key agreement protocols are cryptographic methods that allow two parties to securely establish a shared secret key over a public channel (e.g., the Internet). The core idea is that neither side needs to pre-share secret information; instead, both parties jointly compute a session key based on public parameters and exchanged values. This differs from key distribution, where one party generates the key and transmits it to the other. Key agreement emphasizes joint participation, thereby enhancing security.
Common key agreement protocols include:

Diffie-Hellman (DH)
Elliptic Curve Diffie-Hellman (ECDH)
Pre-Shared Key (PSK) protocols Typical application scenarios include:
TLS/SSL: Secure HTTPS connections using DH/ECDH.
IPSec VPNs: Key negotiation via the Internet Key Exchange (IKE) protocol.
IoT devices: Lightweight PSK or ECC-based protocols such as EDHOC. Nevertheless, key agreement protocols exhibit several drawbacks and limitations:
Vulnerability to Man-in-the-Middle (MITM) Attacks: An attacker may impersonate both parties, establishing separate agreements with each side, thereby intercepting, modifying, or forging communication.
High Computational Overhead: All key agreement protocols involve cryptographic operations (e.g., modular exponentiation, elliptic curve point multiplication), which are resource-intensive. This can be problematic for resource-constrained devices (e.g., IoT nodes, embedded systems) when implementing complex algorithms such as DH or ECDH.
Parameter Sensitivity: For instance, in DH, if the prime modulus p is poorly chosen (e.g., small factors), the discrete logarithm problem becomes easier to solve, reducing security.
Latency Issues: Multi-round message exchanges (e.g., at least two rounds in DH) and heavy computations introduce additional communication and processing delays, making these protocols unsuitable for scenarios requiring ultra-low latency.

Key Distribution Schemes
In a key distribution approach, the same user-specific key is provisioned to both the App client and the application server, enabling them to use this shared key for authentication, encryption, and decryption during communication.
A typical example is WeChat’s per-user key mechanism, where a key is maintained at the user level to secure communication between mini-programs and developer servers. However, this scheme has significant issues, including:

Risk of user key leakage.
Excessive frequency of API calls.
Encryption can only be initiated by mini-programs.
Storage overhead and performance costs.
Challenges with secure key storage.
Inefficient key processing.
Inability to promptly rotate user keys.
Improper handling of expired keys.

Proposed Improvement Scheme
Terminology and Definitions
To enhance clarity and general applicability, this improved scheme is described using standardized terminology:

Smart Device: A device capable of data processing, including smartphones, smart TVs, tablets, as well as IoT devices such as smartwatches, fitness trackers, and smart home devices.
App Client: Also known as the application client, installed on a smart device. It connects to the corresponding application server over the network to access application data and services.
AppID: The unique application identifier, used both to distinguish application servers and to uniquely identify App clients.

Network Architecture
The architecture consists of four main entities: the platform server, smart devices, App clients, and third-party application servers.
In practical deployments, multiple smart devices may each host several App clients. Each App client communicates with its corresponding third-party application server, while third-party servers interact with the platform server.

Core Concept of the Scheme
The platform server maintains a master key for each user account and distributes it to the associated smart devices.

On the device side: The smart device derives per-App user encryption keys from the master key combined with each App’s AppID, and provides them to the respective App clients.
On the server side: The platform server derives identical user encryption keys from the master key combined with the third-party application server’s AppID, and provides them to the corresponding server.

This ensures that the App client and its paired third-party server hold matching encryption keys, enabling secure authentication and communication.

Detailed Procedure

Master Key Management: The platform server maintains a mapping of user accounts to their master keys.
User Login: The smart device logs into the platform server using the user account — an existing and standard process.
Master Key Provisioning: The platform server issues the master key for that user account to the smart device. The smart device securely stores the master key, ensuring it is not directly accessible to App clients.
App Request for Key: When an App client initiates login to a third-party application server, it requests a user encryption key from the smart device.
App Trust Verification: For example, on Android, the smart device verifies the App client’s trustworthiness (e.g., via digital signature validation, trusted source verification).
AppID Retrieval: The smart device retrieves the AppID (e.g., package name) through the Binder interface.
Key Generation: The smart device generates a user encryption key by combining the master key with the AppID. Since AppIDs are unique, this guarantees that the generated key is App-specific.
Key Delivery to Client: The smart device returns the user account and encryption key to the App client.
Client-to-Server Request: The App client sends only the user account (not the encryption key) to the third-party application server when requesting services.
Server Key Request: The third-party application server forwards the user account to the platform server to request the corresponding encryption key.
Server Key Generation: The platform server locates the user’s master key, combines it with the third-party server’s AppID, and generates the same user encryption key as the one derived on the client side.
Server Key Delivery: The platform server returns the user encryption key to the third-party application server.
Mutual Authentication and Encryption: The App client and third-party application server authenticate and exchange data using the identical encryption key.
OpenID Support: For enhanced security and privacy, the system may generate distinct OpenIDs for each App client tied to the same user account.
Key Strengthening Options: In addition to master key and AppID, factors such as timestamps and random nonces may be incorporated in the key generation process to further improve security.

Advantages of the Proposed Scheme
The proposed scheme effectively addresses the limitations of existing solutions and provides significant improvements. Its main advantages include:

Minimal User Interaction: In mainstream authorization scenarios, no forced authorization prompt is required. This greatly reduces user intervention and ensures a smoother user experience.
Cross-Device Compatibility: Supports not only smart devices requiring human interaction (e.g., smartphones) but also non-interactive smart devices (e.g., IoT devices, smart TVs). This eliminates device-type restrictions. For example, a pre-installed App on a smart TV can be linked to the user account without requiring manual interaction.
Simplified Pre-Installation Process: Since user interaction is minimized, Apps preloaded on a device with unified authentication can directly function under the user’s account without additional registration steps.
Independence from External Encryption Protocols: Data transmission between App clients and application servers does not rely on external encryption protocols such as HTTPS, as encryption is natively enforced at the scheme level.
Resistance to Man-in-the-Middle (MITM) Attacks: The scheme prevents attackers from impersonating communication parties during key agreement, thereby protecting against eavesdropping, tampering, or forgery of communication content.
Reduced Computational Overhead: The scheme primarily uses symmetric cryptography and hashing, avoiding computationally heavy operations such as modular exponentiation or elliptic curve point multiplication. This makes it highly suitable for resource-constrained devices (e.g., IoT nodes, embedded systems), where complex key agreement protocols like DH or ECDH could otherwise degrade performance.
Low Latency: Unlike traditional key agreement protocols that require multiple rounds of message exchange and complex computations (e.g., at least two rounds for DH), this scheme avoids additional communication and processing delays. It thus supports real-time scenarios requiring fast response and efficient execution.
Resolution of Existing Key Distribution Issues: The scheme overcomes the problems found in current key distribution mechanisms (e.g., those highlighted in “Problems and Improvements of Mini-Program Key Interfaces”), ensuring more secure, efficient, and maintainable key management.

How to Identify the Phone Number of an Instant Messaging User (Nearby People)

Oliver — Wed, 15 Oct 2025 03:05:18 +0000

On instant messaging applications such as WeChat, WhatsApp, Telegram, LINE, Signal, or Facebook Messenger, if you add a stranger as a contact and can accurately determine their phone number — that sounds pretty incredible, doesn’t it?
Conversely, if someone could accurately figure out your phone number, wouldn’t that be surprising?

In fact, this method is not very complicated — it just requires some effort. The basic idea is as follows:
1. Obtain the local mobile number ranges
For example, a particular city have the mobile number ranges.
An attacker can first collect these number segments to use later for batch matching.
2. Build a mapping between phone numbers and profile photos / display names
Using the app’s “Add Contact” or “Search by Phone Number” feature (without actually sending friend requests), the attacker can iterate through these numbers in bulk.
The system usually displays the user’s profile photo and nickname corresponding to each number.
These results can be stored in a local database that records the mapping between each phone number and its associated photo and nickname —
for example:

Phone Number A → Avatar A, Nickname A
Phone Number B → Avatar B, Nickname B

3. Reverse match using the “Nearby People” feature
Next, the attacker can open the app’s Nearby People or Explore Nearby Users function to view the profile photos and nicknames of nearby strangers.
By performing image similarity matching against the locally stored database, the attacker can infer the possible phone numbers of those nearby users.
This approach can successfully identify part of the users’ phone numbers, though not all — the accuracy mainly depends on whether the target user allows being found via their phone number.
4. Applicability
This technique can be applied to various instant messaging and social networking platforms — any app that allows users to register or be searched by phone number could face similar privacy risks.

Recommendations for Prevention
(1) For individual users:
There is currently no foolproof way to prevent this. Avoid using “Nearby People,” “Find Nearby Friends,” or similar location-based discovery features frequently.
(2) For platform providers:
Instant messaging platforms should enhance their privacy protection mechanisms.
For example, they could allow users to configure different profile photos for different contexts, so that the avatar shown in “Nearby People” is different from the one shown to friends or contacts.

Reverse Methods for Obtaining Phone Numbers and Preventive Measures

Oliver — Wed, 15 Oct 2025 02:33:47 +0000

In group chats on various instant messaging apps (such as WeChat, WhatsApp, Telegram, LINE, Signal, Facebook Messenger, etc.), there are often many group members. In practice, it is possible — and technically not difficult — to indirectly obtain group members’ phone numbers using certain techniques. The principle is as follows:
Step 1 — Obtain the contact list
For example, if a group is a residential owners’ group, an attacker may try to obtain the contact list of the building’s owners. Consider how real estate agents or renovation companies easily get owners’ contact lists — this shows it is not difficult.
If the group is a parents’ group, the attacker will try to obtain the parents’ contact list; if it is an event or conference group, the attacker will try to obtain the attendees’ contact list.
If the actor is a property manager, school teacher, event organizer, or another insider, obtaining these contact lists becomes even easier.

Step 2 — Build mappings between phone numbers and profile pictures
An attacker can, by data scraping or API requests, iterate through phone numbers in the target number ranges and use the instant messaging app’s “add contact” or phone-number-lookup function (without actually adding the contacts) to obtain the profile picture and display name associated with each phone number. The attacker stores these mappings locally — i.e., phone number A → profile picture A / display name A; phone number B → profile picture B / display name B.
This method is not only applicable to WeChat, but also to platforms that allow phone-number-based user lookup, such as WhatsApp, Telegram, LINE, Signal, and Facebook Messenger.

Step 3 — Reverse-match phone numbers
When the attacker obtains the profile pictures of one or more group members, they can compare those pictures with the locally built database using image similarity matching and thereby infer which phone numbers correspond to which group members. For example, profile picture A matches phone number A; profile picture B matches phone number B.
In this way, the attacker can indirectly obtain group members’ phone numbers.

Security and mitigation strategies:
(1) Personal user protection measures
Individual users can disable the “find by phone number” / “search by phone” feature according to each platform’s settings to reduce the risk of reverse matching. For example:
WeChat: Go to Me → Settings → Privacy → Friend Permissions → Ways to Add Me, and turn off the “Mobile Contacts” search entry.
WhatsApp: Adjust “Who can see my profile photo, about, status” under Privacy → Profile Info.
Telegram: Go to Settings → Privacy & Security → Phone Number, and set it to “My Contacts” or “Nobody.”
LINE: In Settings → Privacy Management → Allow others to add me by ID or phone number, turn off the corresponding options.
Signal: Turn off the “Discoverable by phone number” option so only known contacts can find you.
Using these methods severs the pathway by which accounts are discovered via phone number at the source, significantly reducing the chance of being reverse-matched.
(2) Platform security optimization suggestions
Instant messaging platforms (including WeChat, WhatsApp, Telegram, LINE, Signal, Messenger, etc.) could consider system-level privacy protections. For example, platforms could apply differentiated handling of user profile images depending on the lookup method or relationship: show a first (possibly obfuscated or lower-resolution) avatar when a user is found via phone-number search, a second avatar for group-member views, and only show the full-resolution default avatar in established social relationships. This approach would make it harder for attackers to match a user’s profile picture to their phone number.

Security Risks and Improvement Strategies for Multi-Channel OTP Fallback

Oliver — Mon, 15 Sep 2025 06:20:55 +0000

Since March 2023, when WhatsApp officially launched Authentication Templates, major cloud communication platforms (such as Twilio Verify, Vonage, Sinch, Infobip, Message Central, Dexatel, YCloud, and EngageLab) have successively rolled out a “SMS fallback” feature. The core logic is to support “WhatsApp → SMS automatic fallback”: when sending a one-time password (OTP) via the WhatsApp channel fails, the system falls back to the SMS channel. Some vendors refer to this functionality as “Automatic Routing,” “Channel-Fallback Logic,” or “OTP Resend.”

However, current mainstream implementations present significant security risks that warrant serious industry attention.
The fundamental design principle of OTPs is “one-time validity”—a verification code should be used only once and its exposure strictly limited. Yet, the current approach of resending the same OTP across multiple channels (WhatsApp + SMS) inherently violates this principle, leading to the following risks:
1. Significantly expanded attack surface
Multi-channel transmission requires the OTP to be exposed simultaneously to the WhatsApp server, SMS gateways, and end-user devices across multiple systems and networks. Any single weak point—such as communication interception, server vulnerabilities, or device malware—may become an attack entry, dramatically increasing the probability of OTP compromise.
2. More covert identity misuse risks
Example attack path: if the WhatsApp server, due to misconfiguration or compromise, receives the OTP from the cloud communication provider but maliciously returns a “delivery failed” webhook, the platform mistakenly deems the WhatsApp channel unavailable and triggers SMS fallback to resend the OTP. By the time the user attempts verification, the system rejects the OTP as already used—since the attacker has already intercepted and exploited it. The user may wrongly assume they entered the code incorrectly, the OTP expired, or the system malfunctioned, while in reality the OTP was stolen through the manipulated server response.
3. Violation of security baselines and compliance requirements
Reusing the same OTP across multiple channels directly contravenes the Principle of Least Privilege, which requires sensitive information to be transmitted only in the minimal necessary form and scope. In highly regulated industries such as finance, payments, and healthcare, this design not only fails to meet strict requirements in international standards like PCI DSS, GDPR, and ISO 27001, but also introduces compliance risks due to insufficient controls.
4. Difficulties in security forensics and accountability
In cases of identity fraud or financial theft, when OTPs are distributed via multiple channels, it becomes extremely challenging for security teams to pinpoint the source of compromise (whether WhatsApp, the SMS gateway, or the end-user device). This ambiguity complicates incident response, hinders forensic analysis, and obscures accountability.

Recommended Improvements
To fundamentally eliminate the security risks of multi-channel OTP reuse, the fallback mechanism should be redesigned:** when the WhatsApp channel fails, the server must generate a brand-new OTP and send it via SMS**.

This approach ensures security through:
Uniqueness: each fallback generates a new, independent OTP, avoiding cross-channel reuse.
Minimized exposure: the OTP is transmitted through only one channel, reducing the attack surface.
Compliance alignment: meets the “one-time validity, single-channel transmission” requirements critical to financial-grade authentication scenarios.

Conclusion
While multi-channel OTP fallback mechanisms improve deliverability and reduce operational costs, the trade-off in security is too severe to ignore. Industry stakeholders must re-evaluate the risk–benefit balance of current designs and prioritize regenerating new OTPs during fallback as a safer alternative—preserving user experience while reinforcing security.

Forem: Oliver​