Authentication method, authentication protection system and computer readable storage medium

Abstract

The invention discloses an authentication method, an authentication protection system and a computer readable storage medium, and the method comprises the steps: carrying out the hash operation of a first mobile phone number of a to-be-authenticated user in a first authentication request through a pre-processing module, obtaining target hash data, replacing the first mobile phone number in the first authentication request with the target hash data, and carrying out the authentication of the to-be-authenticated user. And a second authentication request is obtained, and then the pre-processing module sends the second authentication request to the authentication engine, so that the authentication engine can request the short message gateway to send verification information based on the first mapping table according to target hash data obtained from the second authentication request. By adopting the scheme, the risk of mobile phone number leakage can be reduced while accurate authentication can be carried out, source code level transformation on an authentication engine is avoided, the system transformation cost is reduced, and the pre-processing module can have good compatibility.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an authentication method, an authentication protection system, and a computer-readable storage medium. Background Technology

[0002] In scenarios such as payment, calling specific applications, and login, in order to improve security, an authentication system can send a verification code to the user's mobile phone number to authenticate the user's identity.

[0003] Currently, authentication systems typically store phone numbers directly in plaintext or reversibly, which poses a risk of phone number leakage and unauthorized access to phone numbers by authentication system administrators, resulting in low security. Summary of the Invention

[0004] This application provides an authentication method, an authentication protection system, and a computer-readable storage medium. By introducing a pre-processing module, the risk of mobile phone number leakage can be reduced.

[0005] Firstly, an authentication method is provided, applied to a pre-processing module in a server-side online domain, comprising: obtaining a first authentication request sent by a client to an authentication engine in the server-side online domain, the first authentication request including at least a first mobile phone number of the user to be authenticated; performing a hash operation on the first mobile phone number to obtain target hash data; replacing the first mobile phone number in the first authentication request with the target hash data to obtain a second authentication request; and sending the second authentication request to the authentication engine, enabling the authentication engine to request an SMS gateway to send verification information based on a first mapping table according to the target hash data obtained from the second authentication request; wherein, the first mapping table... The system stores at least one set of encrypted index data, which includes: index hash data and corresponding encrypted data. The index hash data is obtained by the front-end processing module performing a hash operation on the mobile phone number in the authentication request. The encrypted data is obtained by the front-end processing module encrypting the mobile phone number in the authentication request using a first public key. The SMS gateway can obtain the first encrypted data corresponding to the first index hash data that matches the target hash data from the first mapping table, and decrypt the first encrypted data using the first private key corresponding to the first public key to determine the second mobile phone number to which the verification information needs to be sent. The first private key is stored in a privileged online domain or offline domain on the service side.

[0006] In some embodiments, after obtaining the target hash data, the method further includes: querying the first mapping table; if the index hash data in the first mapping table does not match the target hash data, writing a set of ciphertext index data containing the target hash data and the corresponding target ciphertext data into the first mapping table, wherein the target ciphertext data is obtained by the preprocessing module encrypting the first mobile phone number using the first public key.

[0007] In some embodiments, before querying the first mapping table, the method further includes: determining context data corresponding to the first mobile phone number; performing a hash operation using the context data and the first mobile phone number to obtain a first hash value; encrypting the first mobile phone number using the first public key to obtain encrypted data; and obtaining the target ciphertext data based on the first hash value, the encrypted data, and the context data.

[0008] In some embodiments, writing a set of ciphertext index data containing the target hash data and the corresponding target ciphertext data into the first mapping table includes: determining identification information uniquely corresponding to the first authentication request, determining an idempotent key based on the identification information, associating the idempotent key with the target hash data, and writing the target hash data associated with the idempotent key, the target ciphertext data, hash version information, key version information, and audit metadata as a set of ciphertext index data into the first mapping table.

[0009] In some embodiments, performing a hash operation on the first mobile number to obtain target hash data includes: initiating a hash calculation request to the privileged online domain or the offline domain; and obtaining the target hash data returned by the privileged online domain or the offline domain, wherein the target hash data is obtained by performing a hash operation on the first mobile number and the target key using a target hash algorithm.

[0010] In some embodiments, the pre-processing module includes a first pre-processing module disposed at the front end of the authentication engine or a second pre-processing module disposed at the back end of the authentication engine. When the pre-processing module is the first pre-processing module, obtaining the first authentication request sent by the client to the authentication engine in the server-side online domain includes: obtaining the first authentication request from the client; wherein the first pre-processing module is configured to prohibit persistent storage of the first authentication request, and the first authentication request exists only briefly in memory. When the pre-processing module is the second pre-processing module, obtaining the first authentication request sent by the client to the authentication engine in the server-side online domain includes: obtaining the first authentication request from the authentication engine; wherein the authentication engine and the second pre-processing module are configured to prohibit persistent storage of the first authentication request, and the first authentication request exists only briefly in memory.

[0011] Secondly, an authentication method is provided, applied to an authentication engine located in a server-side online domain, comprising: responding to obtaining a second authentication request from a front-end processing module located in the server-side online domain; obtaining target hash data from the second authentication request, wherein the target hash data is determined by the front-end processing module after performing a hash operation on the first mobile phone number of the user to be authenticated in the first authentication request; determining a code-issuing request based on the target hash data; and sending the code-issuing request to an SMS gateway, causing the SMS gateway to send verification information to the client based on a first mapping table; wherein the first mapping table stores at least one set of ciphertext index data, wherein the ciphertext... The index data includes: index hash data and corresponding ciphertext data. The index hash data is obtained by the front-end processing module performing a hash operation on the mobile phone number in the authentication request. The ciphertext data is obtained by the front-end processing module encrypting the mobile phone number in the authentication request using a first public key. The SMS gateway can obtain the first ciphertext data corresponding to the first index hash data that matches the target hash data from the first mapping table, and decrypt the first ciphertext data using the first private key corresponding to the first public key to determine the second mobile phone number to which the verification information needs to be sent. The first private key is stored in the privileged online domain or offline domain on the service side.

[0012] In some embodiments, after obtaining the target hash data from the second authentication request, the method further includes: determining whether there is index hash data matching the target hash data in a second mapping table, wherein the second mapping table stores at least one set of user information index data, and the user information index data includes: index hash data and corresponding user information; After sending the code issuance request to the SMS gateway, causing the SMS gateway to send verification information based on the first mapping table, the method further includes: obtaining a backfill verification code corresponding to the verification information; if the backfill verification code is verified successfully and all index hash data in the second mapping table does not match the target hash data, creating target user information corresponding to the first mobile phone number according to the second authentication request; writing a set of user information index data containing the target hash data and the target user information into the second mapping table; confirming successful authentication of the user to be authenticated, and issuing a login credential to the client.

[0013] In some embodiments, determining the code issuance request based on the target hash data includes: determining the code issuance request based on the target hash data, the hash version information corresponding to the target hash data, the target user information corresponding to the first mobile phone number, the identification information of the second authentication request, a random number, and a signature.

[0014] In some embodiments, the pre-processing module includes a first pre-processing module disposed at the front end of the authentication engine or a second pre-processing module disposed at the back end of the authentication engine. If the pre-processing module is the second pre-processing module, the module further includes: in response to receiving the first authentication request from the client, sending the first authentication request to the second pre-processing module, causing the second pre-processing module to perform a hash operation on the first mobile phone number and replace the first mobile phone number in the first authentication request with the obtained target hash data to obtain the second authentication request; wherein the authentication engine and the second pre-processing module are configured to prohibit persistent storage of the first authentication request, and the first authentication request exists only briefly in memory.

[0015] Thirdly, an authentication method is provided, applied to an SMS gateway in a privileged online or offline domain, comprising: obtaining a code-issuing request from an authentication engine in a service-side online domain; querying a first mapping table based on target hash data in the code-issuing request to determine first ciphertext data corresponding to first index hash data matching the target hash data, wherein the target hash data is determined by a front-end processing module in the service-side online domain after performing a hash operation on the first mobile phone number of the user to be authenticated in the first authentication request, the first mapping table storing at least one set of ciphertext index data, the ciphertext index data including: index hash data and corresponding ciphertext data, wherein the index hash data is obtained by the front-end processing module performing a hash operation on the mobile phone number in the authentication request, and the ciphertext data is obtained by the front-end processing module encrypting the mobile phone number in the authentication request using a first public key; decrypting the first ciphertext data using a first private key corresponding to the first public key to determine a second mobile phone number, wherein the first private key is stored in a privileged online or offline domain on the service side; and sending verification information to the second mobile phone number.

[0016] In some embodiments, the first ciphertext data includes encrypted data, a first hash value, and context data. The step of decrypting the first ciphertext data using a first private key corresponding to the first public key to determine the second mobile phone number includes: decrypting the encrypted data using the first private key to obtain a target mobile phone number; performing a hash operation on the target mobile phone number and the context data to determine a second hash value; if the second hash value matches the first hash value, determining the target mobile phone number as the second mobile phone number; and if the second hash value does not match the first hash value, returning a decryption failure message to the authentication engine.

[0017] Fourthly, an authentication protection system is provided, comprising a front-end processing module located in a service-side online domain and an SMS gateway located in a privileged online or offline domain, wherein the front-end processing module is configured to execute the authentication method described in the first aspect, and the SMS gateway is configured to execute the authentication method described in the third aspect.

[0018] In some embodiments, the authentication protection system can be combined with the authentication engine to form an authentication system.

[0019] Fifthly, a computer-readable storage medium is provided having a computer program / instructions stored thereon, which, when executed by a processor, implement the steps of the authentication method as described in the first, second, or third aspect.

[0020] A sixth aspect provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the authentication method as described in the first, second, or third aspect. Attached Figure Description

[0021] To more clearly illustrate the technical solutions of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a schematic diagram of a system architecture including an authentication system and an associated interactive terminal according to an embodiment of this application; Figure 2 The process of an authentication method according to an embodiment of this application Figure 1 ; Figure 3 The process of an authentication method according to an embodiment of this application Figure 2 ; Figure 4 A flowchart illustrating the process of determining target ciphertext data for the preprocessing module in this application embodiment; Figure 5 This is a flowchart illustrating how the preprocessing module of this application writes a set of encrypted index data into the first mapping table. Figure 6 This is a schematic diagram of another system architecture including an authentication system and an associated interactive terminal according to an embodiment of this application; Figure 7 The process of an authentication method according to an embodiment of this application Figure 3 ; Figure 8 A flowchart illustrating how the SMS gateway determines the second mobile phone number in this embodiment of the application; Figure 9 This is a structural block diagram of an authentication protection system according to an embodiment of this application. Detailed Implementation

[0023] To clearly and completely describe the technical solution of this application, further explanation will be provided below in conjunction with embodiments and accompanying drawings.

[0024] For existing authentication systems, improving the low security of mobile phone numbers typically requires source code-level modification (i.e., directly modifying the code logic that handles mobile phone numbers), which is costly. Firstly, in common authentication systems, mobile phone numbers are often used as the user's primary key or critical index, deeply embedded in the business logic code, potentially appearing in hundreds of code files (such as login, password retrieval, payment binding, risk control auditing, etc.). Developers must modify each file individually and ensure the business logic is correct, requiring a massive amount of work. Secondly, for authentication systems that have been online for many years, they have often undergone modifications by multiple generations of developers, resulting in complex code logic and even outdated programming languages ​​and frameworks, further increasing the difficulty and investment required for source code-level modification.

[0025] To improve the security of mobile phone numbers in the authentication system, and to minimize or avoid source code modifications to the original authentication system (whose core functions are implemented by the authentication engine, which will be referred to as the authentication engine hereafter unless otherwise specified), this application introduces a pre-processing module and an SMS gateway, and adjusts and optimizes the processing flow of the pre-processing module and the SMS gateway.

[0026] The following will first introduce an exemplary system architecture that includes an authentication system and associated interactive terminals, which can apply the authentication method provided in this application; then, the process steps of the authentication method will be further explained; finally, the product form corresponding to the authentication method will be described.

[0027] like Figure 1 As shown, this application exemplifies a system architecture that includes an authentication system and associated interactive terminals.

[0028] The client side may include a client (such as an app, web application, or mini-program) capable of interacting with the server side, and a mobile terminal used to receive verification information. It is understood that the target electronic device containing the client and the aforementioned mobile terminal may be the same device or different devices; this application does not limit this.

[0029] The service side may include a front-end processing module and authentication engine set up in the online domain, as well as an SMS gateway set up in the privileged online domain or offline domain.

[0030] The authentication engine is the core component responsible for handling identity authentication requests, primarily used for user registration, login, changes, and password retrieval. It verifies the legitimacy of a user's identity by checking credentials provided by the user or the system (such as passwords, tokens, certificates, etc.). After successful verification, the authentication engine can also issue and manage user login credentials (such as tokens or sessions) and maintain the user's online status.

[0031] The pre-processing module is mainly used to process requests from the client (intercepting the client or receiving and forwarding the request from the authentication engine), perform pre-processing such as hashing and replacing the phone number in the request, and then pass the processed request to the authentication engine.

[0032] In conventional solutions, the client and authentication engine share an interaction protocol, which is typically defined early in the business deployment phase, with fixed data structures, parameters, and field requirements. However, these protocols often differ across client versions (e.g., iOS, Android, H5). Modifying the interface definition requires significant changes to the authentication engine's processing logic and forces all users to update their clients, a practical challenge. While this solution introduces a pre-processing module, it doesn't alter the existing interaction protocol between the client and authentication engine. The authentication engine can process received information using its original methods, requiring little or no modification. The pre-processing module functions like a plug, easily integrated into the existing system when needed and easily removed or rolled back (e.g., in case of an exception). Therefore, the pre-processing module in this embodiment can be understood as pluggable. This demonstrates that the pre-processing module in this solution exhibits good protocol and architectural compatibility.

[0033] A Short Message Gateway (SMG) is typically a functional entity positioned between a mobile communication network and a public data network to facilitate protocol conversion and data exchange between the Short Message Service Center (SMSC) and the Service Provider (SP). In this embodiment, the SMG, in addition to its conventional functions, also needs to handle processes such as decrypting encrypted phone numbers, enabling the authentication engine to perform phone number-based identity authentication and related functions even without knowing the plaintext phone number.

[0034] The service side can be divided into online domains, privileged online domains, and / or offline domains. These are mainly based on network security architecture, and the differences between the different domains are mainly reflected in network and permissions.

[0035] The online domain, serving as the business execution area, carries real-time business traffic directly accessed via the internet and is a relatively active part of the system. The online domain has broad outbound / inbound network permissions, allowing its modules to easily call external interfaces. In this embodiment, the front-end processing module, authentication engine, and related databases are located within the online domain. The online domain also carries the real-time link between the front-end processing module and the authentication engine, as well as processes hash and ciphertext data corresponding to mobile phone numbers.

[0036] A privileged online domain acts as a buffer between the online domain and underlying security resources. Its modules are primarily responsible for providing controlled key calculations and sensitive operations. A privileged online domain only allows access from specific IP addresses and ports (e.g., HTTPS only). For example, a privileged online domain may only open narrow-bandwidth RPC or API interfaces, disabling common remote management protocols (such as SSH and RDP).

[0037] An offline domain is a region completely isolated from the regular network by strong physical or logical means. Modules within it primarily store the system's most critical and confidential data, providing functions such as key calculations and sensitive operations. Modules in an offline domain typically require dedicated communication channels, such as leased lines, to connect to specific external modules; other external modules cannot directly access these communication channels.

[0038] In the embodiments of this application, the privileged online or offline domain is at least used to carry out controlled decryption processing of ciphertext (such as the first ciphertext data in the embodiments below), and of course, it also stores the private key required for the decryption processing. In some possible implementations, the SMS gateway itself can also be set in the privileged online or offline domain to provide an interface for "on-site decryption and code transmission of ciphertext". In some possible implementations, the storage of core private data such as private keys, as well as sensitive operations such as encryption and decryption, can be implemented through a hardware security module (HSM) and / or a key service (software program running on the server side), and this core private data cannot be exported.

[0039] There are communication connections between the front-end processing module, the authentication engine, and the client, and there is a communication connection between the SMS gateway and the authentication engine.

[0040] In addition to the aforementioned modules, the operator server used to send verification information is also on the service side. Modules such as conventional authentication engines or SMS gateways in this embodiment can request the operator server through the operator's software development kit (SDK) to send verification information to the mobile terminal.

[0041] ‌ The following example, taking the first authentication request received from the client, illustrates the authentication methods executed by the pre-processing module, authentication engine, and SMS gateway during the authentication process. Figure 2 As shown, the authentication method includes the following steps: Step S101: The pre-processing module obtains the first authentication request sent by the client to the authentication engine in the online domain of the server side. The first authentication request includes at least the first mobile phone number of the user to be authenticated.

[0042] In this embodiment, the client can be an application, software, or a combination of hardware and software installed on the target electronic device, such as a mobile phone, tablet computer, laptop computer, desktop computer, or wearable device. For example, in scenarios requiring authentication, such as payment, calling a specific application, or login, the client can prompt the user to be authenticated to enter a first mobile phone number and send a first authentication request including the first mobile phone number to the authentication engine. It is understood that the first authentication request may also include other information, such as a protocol check mark, an anti-replay sequence number, a client type identifier, and a target user information identifier.

[0043] The front-end processing module can intercept the first authentication request, or the authentication engine can immediately forward the first authentication request to the front-end processing module after receiving it, so that the front-end processing module can obtain the first mobile phone number from the first authentication request.

[0044] It should be noted that in the case of authentication engine forwarding, the authentication engine can be configured to prohibit certain other processing of the first authentication request (such as prohibiting the extraction of the first mobile phone number from the first authentication request), and to prohibit persistent storage of the first authentication request and logging operations. Understandably, the first authentication request may reside briefly in the authentication engine's memory. In some possible implementations, after forwarding or subsequent operations on this request are completed, the first authentication request in the memory area can be cleared through automatic reclamation or active deletion, leaving no retrievable residual information.

[0045] In step S102, the preprocessing module performs a hash operation on the first mobile phone number to obtain the target hash data.

[0046] After obtaining the first mobile phone number, the pre-processing module performs a hash operation on the first mobile phone number to obtain the target hash data corresponding to the first mobile phone number. This can be achieved using existing hash operation methods or other possible methods. Several exemplary embodiments are given below.

[0047] In some embodiments of this application, the preprocessing module performs a hash operation on the first mobile phone number to obtain target hash data, including the following steps: Step S1021: The preprocessing module initiates a hash calculation request to the privileged online domain or the offline domain.

[0048] In this embodiment, the service-side privileged online or offline domain pre-stores a target key (pepper) for hash calculation. For example, the target key can be stored in an HSM (Hardware Security Module) or a key service, and these keys only expose an API to the front-end processing module. The front-end processing module can call this API to request hash calculation.

[0049] Step S1022: The preprocessing module obtains the target hash data returned by the privileged online domain or the offline domain.

[0050] In this embodiment, the target hash algorithm can be HMAC (Hash-based Message Authentication Code) or PBKDF (Password-Based Key Derivation Function). After receiving the request from the front-end processing module, the HSM or key service uses the target hash algorithm to perform a hash operation on the first mobile phone number and the target key to obtain the target hash data, and then returns the target hash data to the front-end processing module.

[0051] By incorporating the target key during hash calculations, the complexity of the target hash data is further increased, thereby enhancing security. Furthermore, since the target key is stored in a privileged online or offline domain on the server side, even if an attacker guesses the entire set of phone numbers, they will be unable to generate the same hash data because they do not know the target key, making it difficult to perform an offline exhaustive mapping and further improving security.

[0052] In some embodiments of this application, the preprocessing module uses a target hash algorithm to perform hash operations on the first mobile phone number and the target key to obtain target hash data, which may include: The pre-processing module performs normalization processing on the first mobile phone number to obtain a normalized mobile phone number; The preprocessing module uses the target hash algorithm to perform hash operations on the normalized mobile phone number, target key, tenant salt (i.e., the salt value of the user indicated by the target user information identifier) ​​and hash version information to obtain target hash data.

[0053] In this embodiment, normalization processing may include one or more of the following: whitespace removal, unified country code removal, and format character removal. Normalizing the first mobile phone number helps ensure the consistency of the target hash data in different calculations, avoiding user experience issues caused by whitespace, format characters, etc. For example, if a mobile phone number that has been previously registered and logged in is mistakenly entered with an extra space, the calculated target hash data may not find a matching index in the first mapping table, leading the system to incorrectly determine that the user has not previously registered and log in, requiring re-registration. Furthermore, normalization processing also avoids data redundancy in the first mapping table. Combining the target key, tenant salt, and hash version information to perform hash operations on the normalized mobile phone number accurately associates the first mobile phone number with the target hash data, while increasing the difficulty for attackers to obtain the target hash data, thereby further improving security.

[0054] For example, if the target hash data is phone_hash, the target hash algorithm is HMAC_SHA256, the target key is pepper, the normalized phone number is phone_norm, the tenant salt is tenant_salt, and the hash version information is hash_version, then phone_hash: HMAC_SHA256(pepper, phone_norm || tenant_salt || hash_version).

[0055] In step S103, the preprocessing module replaces the first mobile phone number in the first authentication request with the target hash data to obtain the second authentication request.

[0056] In this embodiment, the pre-processing module replaces the first mobile phone number in the first authentication request with the target hash data to obtain the second authentication request, ensuring that the second authentication request does not contain the plaintext mobile phone number. For example, in the second authentication request, the target hash data is stored in the protocol field corresponding to the original first mobile phone number. This authentication request still follows the original interaction protocol between the client and the authentication engine, and the authentication engine can continue to process the second authentication request according to its original processing logic without requiring source code modifications.

[0057] In step S104, the preprocessing module sends the second authentication request to the authentication engine.

[0058] In this embodiment, the preprocessing module sends the second authentication request to the authentication engine. Since the second authentication request does not include the first mobile phone number, the authentication engine is also unable to obtain and store the first mobile phone number.

[0059] The pre-processing module has the permission to write or query data to the first mapping table. In some embodiments of this application, after the pre-processing module obtains the target hash data, such as... Figure 3 As shown, it also includes the following steps: Step S105: The preprocessing module queries the first mapping table.

[0060] In this embodiment, the first mapping table can be stored in the target database. The first mapping table stores at least one set of ciphertext index data, which includes index hash data and corresponding ciphertext data.

[0061] Each time the front-end processing module receives an authentication request, it can use the same calculation method to calculate the hash and ciphertext data corresponding to the phone number in the authentication request. It then checks if the hash and ciphertext data have been previously stored in the first mapping table. If they have, it means the front-end processing module has previously processed an authentication request containing that phone number. If not, it means the phone number is new to the authentication system, likely belonging to an unregistered user. In this case, the hash and ciphertext data can be stored in the first mapping table for use in subsequent steps and for judgment when the next authentication request is received.

[0062] To facilitate the distinction between the hash data calculated by the preprocessing module based on the current authentication request and the previously stored hash data, in this embodiment, the hash data already stored in the first mapping table is referred to as index hash data.

[0063] In other words, the index hash data is obtained by the front-end processing module performing a hash operation on the mobile phone number in the authentication request, and the ciphertext data is obtained by the front-end processing module encrypting the mobile phone number in the authentication request using the first public key.

[0064] Understandably, for the first mobile phone number in the first authentication request, the hash data calculated this time is the target hash data. The preprocessing module queries the first mapping table and compares the target hash data with the index hash data in the first mapping table. Based on the comparison result, it can determine whether the encrypted data corresponding to the first mobile phone number needs to be calculated in this processing flow, and store it together with the target hash data as a set of encrypted index data in the first mapping table.

[0065] In step S106, if the index hash data in the first mapping table does not match the target hash data, the preprocessing module writes a set of ciphertext index data containing the target hash data and the corresponding target ciphertext data into the first mapping table. The target ciphertext data is obtained by the preprocessing module encrypting the first mobile phone number using the first public key.

[0066] In this embodiment, if none of the index hash data in the first mapping table matches the target hash data, it indicates that there is no ciphertext index data corresponding to the target hash data in the first mapping table. In this case, the pre-processing module uses the first public key to encrypt the first mobile phone number to obtain the corresponding ciphertext data. For easy distinction, the ciphertext data calculated in the current processing flow of the first authentication request can be called the target ciphertext data, which corresponds to the target hash data. Then, the pre-processing module writes a set of ciphertext index data containing the target hash data and the corresponding target ciphertext data into the first mapping table, so that the SMS gateway can obtain the target ciphertext data using the first mapping table.

[0067] When the index hash data in the first mapping table does not match the target hash data, the corresponding ciphertext index data is written into the first mapping table, thus achieving the purpose of recording the mapping relationship between the target hash data and the target ciphertext data. With the first mapping table as storage support, the pre-processing module can completely delete and replace the plaintext phone number in the original authentication request (i.e., the first authentication request) with hash data. This allows the authentication engine to complete the entire processing flow even without accessing the plaintext phone number. Furthermore, it ensures that the SMS gateway reliably obtains the target ciphertext data from the first mapping table, preventing situations where the second mapping table stores user information index data containing the target hash data, but the SMS gateway cannot find the corresponding ciphertext data in the first mapping table. This improves the reliability of the authentication process. This not only laid the foundation for the successful processing of the first authentication request but also established the foundation for the subsequent processing of other authentication requests containing the first phone number.

[0068] It should be noted that, for the pre-processing module, in some implementations, it can only calculate the target hash data if no matching index hash data is found in the first mapping table, thus avoiding repeated encryption calculations and reducing computational overhead in high-concurrency scenarios. In other implementations, it can calculate the target ciphertext data regardless of whether there is a match, using the match result as a prerequisite for whether the target hash data and target ciphertext data need to be written to the first mapping table in this instance.

[0069] It should also be noted that the front-end processing module can be configured to disable persistent storage of authentication requests and the phone numbers contained therein. This ensures that the initial authentication request will only exist briefly in the front-end processing module's memory and will be quickly cleared, reducing the likelihood of the initial phone number being leaked within the front-end processing module.

[0070] The preprocessing module calculates the target ciphertext data, which can be achieved using existing asymmetric encryption methods or other possible methods. Several exemplary embodiments are given below.

[0071] In some embodiments of this application, before the preprocessing module queries the first mapping table, such as Figure 4 As shown, it also includes the following steps: In step S107, the preprocessing module determines the context data corresponding to the first mobile phone number, and performs a hash operation on the context data and the first mobile phone number to obtain the first hash value.

[0072] In this embodiment, the context data may be the AAD (Additional Authenticated Data) of the first mobile phone number. The context data may include one or more of the following: target user information identifier (tenant_id), encrypted object type identifier (field), key version information (key_version) and hash version information (hash_version) of the first key pair (including the first public key and the first private key).

[0073] In some implementations, the target user information identifier can be carried in the request packet when the client initiates an authentication request. Alternatively, the service side can automatically identify it based on the interaction protocol between the client and the authentication engine, the API Key used for the API call in this authentication request, or access credentials. For example, in gateway or proxy mode, the first pre-processing module (such as an API gateway filter or sidecar) can extract the target user information identifier from the request header or request body of the passed authentication request. As another example, in Webhook mode, the authentication engine, as the controller of the business logic, knows which user is currently making the call (possibly identified through the API Key). Subsequently, when the authentication engine calls the first pre-processing module, it passes the identified target user information identifier as a parameter to the first pre-processing module.

[0074] The encrypted object type identifier is mainly used to identify the type of different encrypted objects, such as mobile phone numbers, ID card numbers, bank card numbers, etc. Although the embodiments of this application mainly use mobile phone numbers as encrypted objects, some extended application schemes may also require encryption of other sensitive information. In this case, it is necessary to identify different encrypted object types so that the server can select different processing methods according to different encrypted object types.

[0075] The key version information is mainly used to indicate the version of the first key pair (including the first public key and the first private key) used by the front-end processing module to encrypt the mobile phone number and the SMS gateway set to decrypt it.

[0076] The hash version information is primarily used to indicate the version of the hash algorithm itself used to calculate the first hash value. It should be noted that while both the hash version information here and the hash version information used to calculate the target hash data are used to indicate the hash algorithm version, and may even have the same value in some cases, they are two different entities.

[0077] Due to security compliance requirements, the need for periodic key rotation, or the need to upgrade and switch hash algorithms, the system may generate multiple first key pairs at different times, using different versions of hash algorithms to calculate the first hash value, and then calculate the target ciphertext data and perform corresponding decryption. This not only improves the security of the authentication scheme, but also enables the entire system to support version rotation and the coexistence of new and old versions.

[0078] The preprocessing module binds the context data to the first mobile phone number and then performs a hash operation to obtain a first hash value. In some embodiments, obtaining the first hash value by hashing the context data and the first mobile phone number may include: performing a hash operation using the C1 value under the SM2 encryption standard, the context data, and the first mobile phone number to obtain the first hash value, and then determining the first hash value as the C3 value under the SM2 encryption standard. C1 is a point on an elliptic curve, which is a temporary public key point randomly generated during the encryption process.

[0079] In step S108, the pre-processing module uses the first public key to encrypt the first mobile phone number to obtain encrypted data.

[0080] In step S109, the preprocessing module obtains the target ciphertext data based on the first hash value, encrypted data, and context data.

[0081] In this embodiment, the target ciphertext data includes a first hash value, encrypted data, and context data. For example, the target ciphertext data may conform to the SM2 encryption standard, using C1||C3||C2 encoding, where C3 is the first hash value, C2 is the encrypted data, and C1 is a point on an elliptic curve. After decrypting the target ciphertext data, the C3 value can be used for integrity verification.

[0082] By incorporating context data corresponding to the first mobile phone number during the encryption process, the ciphertext data is prevented from being reused or replaced across contexts, thus improving the security of the target ciphertext data.

[0083] Optionally, in some embodiments, the first mobile phone number can be pre-normalized to determine the normalized mobile phone number, and the pre-processing module can use the first public key to encrypt the normalized mobile phone number and context data (if any) to obtain encrypted data.

[0084] For example, if the target ciphertext data conforms to the SM2 encryption standard, then: phone_sm2_ciphertext=SM2_Encrypt(pubKey(key_version), normalize(phone)).

[0085] Here, phone_sm2_ciphertext represents the ciphertext data, SM2_Encrypt represents SM2 encryption, pubKey represents the first public key, key_version represents the key version information of the first public key, and normalize(phone) represents the normalized phone number.

[0086] In some embodiments of this application, the preprocessing module writes a set of ciphertext index data, including target hash data and corresponding target ciphertext data, into a first mapping table, such as... Figure 5 As shown, it includes the following steps: In step S1061, the preprocessing module determines the unique identifier information corresponding to the first authentication request, determines the idempotent key based on the identifier information, and associates the idempotent key with the target hash data.

[0087] In this embodiment, the idempotency key is a key that uniquely identifies this specific operation. The purpose is to ensure that when the same request is sent repeatedly (e.g., due to network timeout causing the client to retry), the system will not create duplicate records, but will only produce one result. The identification information may include the process identifier (flow+) corresponding to the process to which the first authentication request belongs (e.g., login process, verification process, etc.) and the request identifier (req_id) corresponding to the first authentication request. The idempotency key (idempotency_key) is determined based on the identification information: idempotency_key = flow + ":" + req_id. The idempotency key is then associated with the target hash data.

[0088] In step S1062, the preprocessing module writes the target hash data, target ciphertext data, hash version information, key version information, and audit metadata associated with the idempotent key into the first mapping table as a set of ciphertext index data.

[0089] In this embodiment, the target hash data of the associated idempotent key is used as the primary key. The target hash data (phone_hash), target ciphertext data (phone_sm2_ciphertext), hash version information (hash_version), key version information (key_version), and audit meta information (audit_meta) of the associated idempotent key are written into the first mapping table as a set of ciphertext index data. A set of ciphertext index data can be represented as: (phone_hash ->phone_sm2_ciphertext, key_version, hash_version, audit_meta).

[0090] By determining the idempotent key and writing the target hash data associated with the idempotent key into the first mapping table, the duplicate creation of records when the same request is sent repeatedly is avoided. This ensures that the ciphertext is aligned with the index and is auditable and traceable. Furthermore, the index hash data in the first mapping table can be used for retrieval and auditing, giving the first mapping table the retrieval capability equivalent to storing plaintext mobile phone numbers, thus enabling the determination of the corresponding ciphertext data without needing the plaintext.

[0091] In some embodiments of this application, the pre-processing module can be located at the front end of the authentication engine. For ease of distinction, such a pre-processing module is referred to as the first pre-processing module, and its location can be exemplarily seen in [reference needed]. Figure 1 .

[0092] When the front-end processing module is the first front-end processing module, obtaining the first authentication request sent by the client to the authentication engine in the online domain on the server side includes: the front-end processing module obtaining the first authentication request from the client. That is, the first authentication request sent by the client arrives at the front-end processing module first. The first front-end processing module is configured to prohibit persistent storage of the first authentication request; the first authentication request only exists in memory for a short time, reducing the possibility of the first mobile phone number being leaked in the first front-end processing module.

[0093] In other embodiments of this application, the pre-processing module may be located at the back end of the authentication engine. For ease of distinction, such a pre-processing module is referred to as the second pre-processing module, and its location can be exemplarily seen in [reference needed]. Figure 6 .

[0094] When the front-end processing module is a second front-end processing module, obtaining the first authentication request sent by the client to the authentication engine in the online domain on the server side includes: the front-end processing module obtaining the first authentication request from the authentication engine. That is, the first authentication request sent by the client first reaches the authentication engine. The authentication engine and the second front-end processing module are configured to prohibit persistent storage of the first authentication request; the first authentication request only exists in memory for a short time, reducing the possibility of the first mobile phone number being leaked in the second front-end processing module and the authentication engine.

[0095] In this embodiment, the first pre-processing module may include, for example, any one of an API gateway filter, a reverse proxy middleware, or a Sidecar, and the second pre-processing module may include, for example, a Webhook.

[0096] By employing pre-processing modules of different types and deployment forms, the security of the authentication process is improved while the flexibility of authentication methods is enhanced, making it easier to cover multiple scenarios for both existing (online) and incremental authentication systems. For closed authentication systems with completely unmodifiable source code, the first pre-processing module can achieve automatic traffic desensitization, enabling direct plug-and-play upgrades. For authentication systems with open standard interfaces, the second pre-processing module enables hook calls at the logic layer, requiring minimal modification to the original authentication system and reducing integration complexity.

[0097] like Figure 2 As shown, after step S104, the authentication method further includes: In step S201, the authentication engine responds by obtaining a second authentication request from the pre-processing module in the online domain on the service side, and obtains the target hash data from the second authentication request.

[0098] In this embodiment, the second authentication request includes target hash data. After the authentication engine obtains the second authentication request from the front-end processing module, it obtains the target hash data from the second authentication request.

[0099] In step S202, the authentication engine determines the code issuance request based on the target hash data.

[0100] In this embodiment, the code sending request is used to enable the SMS gateway to send verification information to the client. The authentication engine determines the code sending request based on the target hash data, so that the code sending request includes the target hash data.

[0101] In some embodiments of this application, determining the code sending request based on the target hash data includes: The authentication engine determines the code issuance request based on the target hash data, the hash version information corresponding to the target hash data, the target user information corresponding to the first mobile phone number, the identifier information of the second authentication request, the random number, and the signature.

[0102] In this embodiment, the authentication engine determines the hash version information (hash_version) corresponding to the target hash data (phone_hash), the target user information (tenant_id) corresponding to the first mobile phone number, the identifier information (req_id), the random number (nonce), and the signature (HMAC) of the second authentication request, and combines them into a code issuance request. In this way, the code issuance request is determined by multiple data including the target hash data, which improves the security of the code issuance request during the transmission process.

[0103] In step S203, the authentication engine sends the code issuance request to the SMS gateway.

[0104] like Figure 2 As shown, after step S203, the authentication method further includes: In step S301, the SMS gateway obtains a code sending request from the authentication engine located in the online domain on the service side.

[0105] In step S302, the SMS gateway queries the first mapping table based on the target hash data in the code sending request to determine the first ciphertext data corresponding to the first index hash data that matches the target hash data.

[0106] The SMS gateway has the authority to query and read data from the first mapping table, while the authentication engine does not have (or is set to have no such authority). The SMS gateway obtains the target hash data from the sending request and uses the target hash data to query the first mapping table to determine the first ciphertext data corresponding to the first index hash data that matches the target hash data.

[0107] Understandably, if the pre-processing module has not processed the first mobile number before this authentication request, the first index hash data and the first ciphertext data here are the target hash data and target ciphertext data stored in the first mapping table by the pre-processing module in step S106 above. If the pre-processing module has previously processed the first mobile number, the first index hash data and the first ciphertext data here can be a set of previously stored ciphertext index data.

[0108] In step S303, the SMS gateway uses the first private key corresponding to the first public key to decrypt the first encrypted data and determine the second mobile phone number. The first private key is stored in the privileged online domain or offline domain on the service side.

[0109] In this embodiment, for example, when the SMS gateway itself is in a privileged online domain and the first private key is stored by a key service in the privileged online domain, the SMS gateway can request the key service to provide decryption services through a specific API, so that the SMS gateway can obtain the second mobile phone number decrypted from the first ciphertext data by the key service using the first private key. As another example, when the SMS gateway itself is in a privileged online domain, but the first private key is stored in an HSM in an offline domain, the SMS gateway can request the HSM to provide decryption services through another specific API, so that the SMS gateway can obtain the second mobile phone number decrypted by the HSM using the first private key. Using this method, the first private key adheres to the principle of not leaving the key service or HSM during the decryption process, resulting in higher security.

[0110] Understandably, if the SMS gateway can correctly decrypt the message, the decrypted second mobile number should be the same as the first mobile number in the authentication request. In this case, the mobile terminal the user expects to use to receive verification information (based on the first mobile number) and the mobile terminal the SMS gateway will actually use to send verification information (based on the second mobile number) are the same device. However, if decryption fails, the decrypted second mobile number will be different from the first mobile number, and the user will obviously be unable to receive the verification information through their expected mobile terminal.

[0111] In some embodiments of this application, the first encrypted data includes encrypted data, a first hash value, and context data. The SMS gateway decrypts the first encrypted data using a first private key corresponding to the first public key to determine the second mobile phone number, such as... Figure 8 As shown, it includes the following steps: In step S305, the SMS gateway uses the first private key to decrypt the encrypted data and obtain the target mobile phone number.

[0112] In this embodiment, the first ciphertext data includes encrypted data, a first hash value, and context data. After obtaining the first ciphertext data, the SMS gateway first uses the first private key to decrypt the encrypted data to obtain the target mobile phone number.

[0113] In step S306, the SMS gateway performs a hash operation on the target mobile number and context data to determine the second hash value.

[0114] The SMS gateway uses the same hash algorithm and context data as the front-end processing module to determine the first hash value, performs a hash operation on the target mobile number and context data, determines the second hash value, and determines whether the first hash value is consistent with the second hash value.

[0115] In step S307, if the second hash value matches the first hash value, the SMS gateway determines the target mobile phone number as the second mobile phone number.

[0116] In this embodiment, if the second hash value is consistent with the first hash value, it means that the integrity verification is successful, and the SMS gateway determines the target mobile phone number as the second mobile phone number.

[0117] In step S308, if the second hash value is inconsistent with the first hash value, the SMS gateway returns a decryption failure message to the authentication engine.

[0118] In this embodiment, if the second hash value is inconsistent with the first hash value, it means that the integrity verification fails. The SMS gateway returns a decryption failure message to the authentication engine, and the authentication engine can return an authentication failure message to the client.

[0119] By using contextual data, the integrity of the first encrypted data can be verified, further improving security.

[0120] In step S304, the SMS gateway sends verification information to the second mobile number.

[0121] In this embodiment, the verification information may be, for example, an SMS message including a verification code, which may be a six-digit number.

[0122] After obtaining verification information from the mobile device, the user to be authenticated can fill in the verification code from the verification information in the fill-in area of ​​the client authentication interface. The client then sends the verification code back to the authentication engine, which can use the verification code to determine whether the user who initiated the first authentication request is a legitimate user.

[0123] The authentication engine can store a database containing user information. In conventional schemes, this database typically stores user IDs and their corresponding phone numbers. To ensure the security of user phone numbers, some schemes use a key (such as a symmetric key) to encrypt the phone number, obtaining ciphertext, which is then stored in the database. When needed, the authentication engine decrypts the ciphertext from the database. The administrator of the authentication system has access to the authentication system server and possesses both the ciphertext and the decryption key, thus easily obtaining the phone numbers of all users.

[0124] In this embodiment, when a user registers for the first time using a mobile phone number, the authentication engine can store user information index data through a second mapping table. This index data also includes the user ID, but the user's mobile phone number is replaced with index hash data calculated by the pre-processing module. For the currently processed authentication request (e.g., the aforementioned second authentication request), the authentication engine only needs to check in the second mapping table whether there is index hash data matching the target hash data to determine whether the user is registering for the first time or has already registered. If the user is already registered, the authentication engine can use the index hash data as an index to obtain other associated information about the user and perform the corresponding subsequent verification steps for registered users. If the user is registering for the first time, the authentication engine can also perform new registration verification steps and create an account for the user after successful verification, recording the associated user information.

[0125] By adopting this approach, the steps in the authentication engine that previously used the user's mobile phone number as an index can be directly replaced with index hash data. Firstly, this avoids storing encrypted mobile phone numbers that can be decrypted and viewed by the authentication engine administrator. This prevents the administrator from obtaining either the encrypted mobile phone number or the first private key needed for decryption, thus preventing unauthorized access to the phone number. Secondly, it also avoids decrypting and using plaintext mobile phone numbers within the authentication engine. If the authentication engine is attacked by an external attacker, while the attacker may obtain other information within the engine, they will find it difficult to obtain the user's plaintext mobile phone number. This ensures that the information obtained by the attacker remains anonymized (for example, knowing that a user's account balance is 1000 yuan, but not knowing who that user is in the real world), thereby protecting user privacy. Similarly, during auditing, even if auditors need to verify user-related information, they only see index hash data in the audit system. Without authorized decryption, the auditing process itself will not expose the user's plaintext mobile phone number. Thirdly, the authentication engine only changes the input parameters from plaintext mobile phone numbers to index hash data, but the business logic of the authentication engine itself (specifically determined by the source code) remains unchanged, thus avoiding or reducing the need for source code-level modifications to the authentication engine.

[0126] After sending the code sending request to the SMS gateway, such as Figure 7 As shown, it also includes the following steps: In step S204, the authentication engine obtains the verification code corresponding to the verification information.

[0127] In this embodiment, the second mapping table represents the mapping relationship between index hash data and corresponding user information. The second mapping table can be stored in the same online domain database as the first mapping table, or it can be stored in a different database. The authentication engine can obtain the backfill verification code corresponding to the verification information from the client.

[0128] In step S205, if the verification code is successfully filled in and all index hash data in the second mapping table does not match the target hash data, the authentication engine creates the target user information corresponding to the target hash data.

[0129] In this embodiment, the authentication engine verifies the received verification code, for example, by comparing it with the verification code received from the SMS gateway to see if they are the same. If the verification passes, and all index hash data in the second mapping table does not match the target hash data, then the target user information corresponding to the target hash data is created.

[0130] In step S206, the authentication engine writes a set of user information index data, containing the target hash data and the target user information, into the second mapping table. This establishes the mapping relationship between the target hash data and the target user information.

[0131] Understandably, if the verification code is successfully entered and an index hash that matches the target hash data can be found in the second mapping table, there is no need to create a new account. Instead, the target user information corresponding to the index hash data in the second mapping table is retrieved to execute subsequent steps.

[0132] In step S207, the authentication engine confirms that the authentication of the user to be authenticated is successful and issues a login credential to the client.

[0133] In this embodiment, the login credentials may include, for example, an access token or a session identifier. The authentication engine confirms successful authentication of the user and issues a login credential to the client. The client can then use the login credential to log in to the corresponding interface or interact with the target application. In some implementations, the login credential may be associated with target user information, for example, containing partial information from the target user information or generating the login credential based on this partial information.

[0134] By writing the target hash data and target user information into the second mapping table, a mapping relationship between the target hash data and target user information is established. Subsequently, equivalent retrieval can be performed based on the index hash data in the second mapping table to accurately locate the target user information, thereby enabling the auditing and querying of user information.

[0135] By applying the above technical solution, the pre-processing module performs a hash operation on the first mobile phone number of the user to be authenticated in the first authentication request to obtain target hash data. This target hash data is then used to replace the first mobile phone number in the first authentication request to obtain a second authentication request. The pre-processing module then sends the second authentication request to the authentication engine, enabling the authentication engine to request the SMS gateway to send verification information based on the first mapping table, according to the target hash data obtained from the second authentication request. The SMS gateway can obtain the first ciphertext data corresponding to the first index hash data matching the target hash data from the first mapping table, and decrypt the first ciphertext data using the first private key corresponding to the first public key to determine the second mobile phone number to be sent verification information. The first private key is stored in the privileged online or offline domain on the server side. In this way, the pre-processing module performs hash operations and encryption on the mobile phone number of the user to be authenticated, while the subsequent authentication engine uses the target hash data as an index to authenticate the user. This ensures accurate authentication while avoiding the authentication engine storing and using the plaintext mobile phone number during the authentication process. Furthermore, since the first private key required for decryption is stored in the privileged online or offline domain on the server side, the authentication engine and front-end processing modules in the online domain do not have decryption capabilities. This establishes a mutually exclusive permission architecture where the online domain has storage but no decryption rights, while the privileged online / offline domain has decryption rights but no index. This prevents authentication engine administrators from obtaining phone numbers without authorization. Both of these aspects reduce the risk of phone number leakage. In addition, applying this technical solution can avoid or reduce source code modifications to the authentication engine, lowering system modification costs and ensuring good compatibility of the front-end processing module.

[0136] This application also provides an authentication protection system, such as... Figure 9 As shown, it includes a front-end processing module located in the online domain of the service side and an SMS gateway located in the privileged online domain or offline domain. The front-end processing module is configured to execute the authentication method corresponding to the front-end processing module in the embodiments of this application, and the SMS gateway is configured to execute the authentication method corresponding to the SMS gateway in the embodiments of this application.

[0137] This application also provides a computer-readable storage medium storing a computer program / instructions thereon, which, when executed by a processor, implements the steps of the authentication method as described in the various embodiments of this application.

[0138] This application also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the authentication method as described in the various embodiments of this application.

[0139] The processors mentioned above can be general-purpose processors, including CPUs, NPs (Network Processors), etc.; they can also be DSPs (Digital Signal Processors), ASICs (Application Specific Integrated Circuits), FPGAs (Field Programmable Gate Arrays), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0140] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0141] The above embodiments are merely exemplary embodiments of this application and are not intended to limit this application. The scope of protection of this application is defined by the claims. Those skilled in the art can make various modifications, equivalent substitutions, or improvements to this application within its substance and scope of protection, and such modifications, equivalent substitutions, or improvements should also be considered to fall within the scope of protection of this application.

[0142] The structural and functional details shown in this application specification and accompanying drawings are intended to enable those skilled in the art to substantially understand and implement this application. To maintain clarity regarding the core inventive points of this application, well-known technical details (such as basic network protocols, conventional database read / write operations, etc.) may not be described in detail.

[0143] In this application, the phrases "in one embodiment," "in some embodiments," or "in alternative embodiments" are used to refer to one or more of the same or different embodiments according to this application. The various embodiments in this application can be combined with each other without conflict.

Claims

1. An authentication method, characterized in that, The front-end processing module, applied in the online domain on the server side, includes: Obtain the first authentication request sent by the client to the authentication engine in the online domain on the server side. The first authentication request includes at least the first mobile phone number of the user to be authenticated. Perform a hash operation on the first mobile phone number to obtain the target hash data; Replace the first mobile phone number in the first authentication request with the target hash data to obtain the second authentication request; The second authentication request is sent to the authentication engine, enabling the authentication engine to request the SMS gateway to send verification information based on the target hash data obtained from the second authentication request, according to the first mapping table. The first mapping table stores at least one set of encrypted index data, which includes index hash data and corresponding encrypted data. The index hash data is obtained by the front-end processing module performing a hash operation on the mobile phone number in the authentication request, and the encrypted data is obtained by the front-end processing module encrypting the mobile phone number in the authentication request using a first public key. The SMS gateway can obtain the first encrypted data corresponding to the first index hash data matching the target hash data from the first mapping table, and decrypt the first encrypted data using the first private key corresponding to the first public key to determine the second mobile phone number to which the verification information needs to be sent. The first private key is stored in a privileged online or offline domain on the service side.

2. The authentication method as described in claim 1, characterized in that, After obtaining the target hash data, the process also includes: Query the first mapping table; If none of the index hash data in the first mapping table matches the target hash data, a set of ciphertext index data containing the target hash data and the corresponding target ciphertext data is written into the first mapping table. The target ciphertext data is obtained by the preprocessing module encrypting the first mobile phone number using the first public key.

3. The authentication method as described in claim 2, characterized in that, Before querying the first mapping table, the method further includes: Determine the context data corresponding to the first mobile phone number, and perform a hash operation using the context data and the first mobile phone number to obtain a first hash value; The first mobile phone number is encrypted using the first public key to obtain encrypted data; The target ciphertext data is obtained based on the first hash value, the encrypted data, and the context data.

4. The authentication method as described in claim 2, characterized in that, The step of writing a set of ciphertext index data containing the target hash data and the corresponding target ciphertext data into the first mapping table includes: Determine the unique identifier information corresponding to the first authentication request, determine the idempotent key based on the identifier information, and associate the idempotent key with the target hash data; The target hash data associated with the idempotent key, the target ciphertext data, the hash version information, the key version information, and the audit metadata are written as a set of ciphertext index data into the first mapping table.

5. The authentication method as described in claim 1, characterized in that, The step of performing a hash operation on the first mobile phone number to obtain the target hash data includes: Initiate a hash calculation request to the privileged online domain or the offline domain; Obtain the target hash data returned by the privileged online domain or the offline domain, wherein the target hash data is obtained by performing a hash operation on the first mobile phone number and the target key using a target hash algorithm.

6. The authentication method as described in claim 1, characterized in that, The pre-processing module includes a first pre-processing module disposed at the front end of the authentication engine or a second pre-processing module disposed at the back end of the authentication engine. When the front-end processing module is the first front-end processing module, obtaining the first authentication request sent by the client to the authentication engine in the online domain of the service side includes: obtaining the first authentication request from the client; wherein, the first front-end processing module is configured to prohibit persistent storage of the first authentication request, and the first authentication request only exists in memory for a short time; When the front-end processing module is the second front-end processing module, obtaining the first authentication request sent by the client to the authentication engine in the online domain on the service side includes: obtaining the first authentication request from the authentication engine; wherein the authentication engine and the second front-end processing module are configured to prohibit persistent storage of the first authentication request, and the first authentication request only exists in memory for a short time.

7. An authentication method, characterized in that, Authentication engines applied in online domains on the server side include: In response to receiving a second authentication request from a front-end processing module in the online domain on the service side, target hash data is obtained from the second authentication request. The target hash data is determined by the front-end processing module after performing a hash operation on the first mobile phone number of the user to be authenticated in the first authentication request. The code sending request is determined based on the target hash data; The code sending request is sent to the SMS gateway, which then sends verification information to the client based on a first mapping table. The first mapping table stores at least one set of encrypted index data, which includes index hash data and corresponding encrypted data. The index hash data is obtained by the front-end processing module performing a hash operation on the mobile phone number in the authentication request, and the encrypted data is obtained by the front-end processing module encrypting the mobile phone number in the authentication request using a first public key. The SMS gateway can obtain the first encrypted data corresponding to the first index hash data matching the target hash data from the first mapping table, and decrypt the first encrypted data using the first private key corresponding to the first public key to determine the second mobile phone number to which the verification information needs to be sent. The first private key is stored in a privileged online or offline domain on the service side.

8. The authentication method as described in claim 7, characterized in that, After obtaining the target hash data from the second authentication request, the method further includes: determining whether there is index hash data matching the target hash data in the second mapping table, wherein the second mapping table stores at least one set of user information index data, and the user information index data includes: index hash data and corresponding user information; After sending the code issuance request to the SMS gateway, causing the SMS gateway to send verification information based on the first mapping table, the method further includes: Obtain the verification code corresponding to the verification information; If the verification code is successfully filled in and all index hash data in the second mapping table does not match the target hash data, target user information corresponding to the first mobile phone number is created according to the second authentication request. Write a set of user information index data containing the target hash data and the target user information into the second mapping table; Once the authentication of the user to be authenticated is confirmed to be successful, a login credential is issued to the client.

9. The authentication method as described in claim 7, characterized in that, The step of determining the code sending request based on the target hash data includes: The code issuance request is determined based on the target hash data, the hash version information corresponding to the target hash data, the target user information corresponding to the first mobile phone number, the identifier information of the second authentication request, the random number, and the signature.

10. The authentication method as described in claim 7, characterized in that, The pre-processing module includes a first pre-processing module disposed at the front end of the authentication engine or a second pre-processing module disposed at the back end of the authentication engine. If the pre-processing module is the second pre-processing module, it further includes: In response to receiving the first authentication request from the client, the first authentication request is sent to the second pre-processing module, which performs a hash operation on the first mobile number and replaces the first mobile number in the first authentication request with the obtained target hash data to obtain the second authentication request; wherein, the authentication engine and the second pre-processing module are configured to prohibit persistent storage of the first authentication request, and the first authentication request only exists in memory for a short time.

11. An authentication method, characterized in that, SMS gateways used in privileged online or offline domains include: Obtain the code issuance request from the authentication engine located in the online domain on the server side; Based on the target hash data in the code issuance request, the first mapping table is queried to determine the first ciphertext data corresponding to the first index hash data that matches the target hash data. The target hash data is determined by the front-end processing module in the online domain on the service side after performing a hash operation on the first mobile phone number of the user to be authenticated in the first authentication request. The first mapping table stores at least one set of ciphertext index data. The ciphertext index data includes: index hash data and corresponding ciphertext data. The index hash data is obtained by the front-end processing module performing a hash operation on the mobile phone number in the authentication request. The ciphertext data is obtained by the front-end processing module encrypting the mobile phone number in the authentication request using the first public key. The first encrypted data is decrypted using the first private key corresponding to the first public key to determine the second mobile phone number. The first private key is stored in the privileged online domain or offline domain on the server side. Send verification information to the second mobile number.

12. The authentication method as described in claim 11, characterized in that, The first ciphertext data includes encrypted data, a first hash value, and context data. The step of decrypting the first ciphertext data using a first private key corresponding to the first public key to determine the second mobile phone number includes: The encrypted data is decrypted using the first private key to obtain the target mobile phone number; Perform a hash operation on the target mobile number and the context data to determine the second hash value; If the second hash value matches the first hash value, the target mobile phone number is determined to be the second mobile phone number.

13. An authentication protection system, characterized in that, The system includes a front-end processing module located in a service-side online domain and an SMS gateway located in a privileged online or offline domain. The front-end processing module is configured to perform the authentication method as described in any one of claims 1-6, and the SMS gateway is configured to perform the authentication method as described in any one of claims 11-12.

14. A computer-readable storage medium having a computer program / instructions stored thereon, characterized in that, When executed by a processor, the computer program / instruction implements the steps of the authentication method as described in any one of claims 1-6, 7-10, or 11-12.

15. A computer program product comprising a computer program / instructions, characterized in that, When executed by a processor, the computer program / instruction implements the steps of the authentication method as described in any one of claims 1-6, 7-10, or 11-12.

Images