Login method and device, electronic equipment and storage medium

Abstract

The invention relates to a login method and device, electronic equipment and a storage medium, and the method comprises the steps: searching an access token which is associated with a mobile phone number and is in an unused state based on the mobile phone number in a received number pre-fetching request of a client; and if the mobile phone number is not found, generating a target mask according to the risk level of the mobile phone number and a corresponding mask generation strategy, creating target access token information, and returning the target access token information to the client. And returning corresponding response information in response to the received replacement request of the client. The number prefetching request of the access token in an unused state is blocked, so that a malicious user is prevented from bypassing a replacement request to hoard the access token; the dynamic masks are generated on the basis of grading, the characteristics of unpredictability and non-multiplexing are achieved, and the malicious login behavior of bypassing the replacement request through the cache masks is avoided. Through a state linkage closed loop and a dynamic mask, an active immune and self-adaptive response safety system is constructed, the system is non-inductive to benign users and accurately attacks malicious users, and unification of safety and convenience is realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computers, and in particular to a login method and device, an electronic device, and a storage medium. BACKGROUND

[0002] With the development of the Internet, the convenience of one-click login is increasingly popular among users. Many mobile application vendors use one-click login to guide users to log in. Through the operator number taking service, the user's IP and other information are combined to obtain a mobile phone number to complete login authentication.

[0003] However, in the existing one-click login method, the mask mode of the same mobile phone number is stable. Merchants can bind the mask to the real mobile phone number through local caching, and subsequent login directly matches the mask to skip the replacement step, thereby destroying the login security. Moreover, multiple pre-fetching number requests are allowed, and access tokens are accumulated without completing the replacement operation, which leads to user information security risks, malicious avoidance of billing verification by agents, and other problems. SUMMARY

[0004] The present application provides a login method, device, electronic device, and storage medium to solve the problem of fixed mask mode and pre-fetching number request mechanism in the prior art, which leads to user skipping the replacement operation and malicious avoidance of billing verification.

[0005] In a first aspect, the present application provides a login method, which includes: receiving a pre-fetching number request of a client; obtaining a mobile phone number in the pre-fetching number request, and searching for an access token in an unused state associated with the mobile phone number; in the case where the access token in the unused state is not found, determining a risk level of the mobile phone number, and generating a target mask associated with the mobile phone number according to a corresponding mask generation strategy according to the risk level; creating target access token information, and returning the target access token information and the target mask to the client; in response to receiving a replacement request of the client, verifying the access token information in the replacement request, and returning response information according to the verification result.

[0006] In a possible implementation, the method further includes: in the case where the access token in the unused state is found, returning prompt information, the prompt information being used to prompt the user to complete the last incomplete replacement operation.

[0007] In a possible implementation, the access token further includes an expired state, and the method further includes: According to a set period, the state of the access token is scanned, and if it is found that the access token in the unused state has expired, the state of the access token is modified to expired.

[0008] In a possible implementation, the determining the risk level of the mobile phone number comprises: Obtaining risk feature information of at least one dimension corresponding to the mobile phone number comprises: Historical risk features are used to represent the number of times that the mobile phone number is identified to have one or more unused state access tokens associated with the mobile phone number in historical login behaviors; Request frequency features are used to represent the number of pre-number request times of the mobile phone number per unit time; Replacement ratio features are used to represent the ratio of the number of successful pre-number request times of the mobile phone number to the number of successful replacement request times; According to the risk feature information, the risk level of the mobile phone number is determined.

[0009] In a possible implementation, the generating a target mask associated with the mobile phone number according to the risk level and a corresponding mask generation strategy comprises: If the risk level is low risk, a first strategy is determined as the target generation strategy; wherein the first strategy is to retain the last four digits of the mobile phone number; If the risk level is medium risk, a second strategy is determined as the target generation strategy; wherein the second strategy is to determine the number of tail number digits of the mobile phone number based on a time period function; If the risk level is high risk, a third strategy is determined as the target generation strategy; wherein the third strategy is to determine the starting position and continuous length of the exposed digits in the mobile phone number based on client information; Based on the target generation strategy, the mobile phone number is processed to generate a corresponding target mask.

[0010] In a possible implementation, the creating target access token information comprises: Generating a unique token string as an access token; Setting the initial state of the access token to unused; Establishing an association relationship between the access token and the mobile phone number and the target mask; Determining access token information carrying the initial state and the association relationship as target access token information.

[0011] In a possible implementation, the verifying the access token information in the replacement request comprises returning response information according to a verification result, comprising: parsing the access token information to obtain a state of the access token; if the state of the access token is unused, performing a first operation; wherein the first operation comprises: updating the state of the access token to used, and returning a real mobile phone number associated with the access token to the client; if the state of the access token is not unused, performing a second operation; wherein the second operation comprises: returning replacement error information to the client.

[0012] In a second aspect, the present application provides a login device, the device comprising: a pre-fetch number request module configured to receive a pre-fetch number request of a client; an access token searching module configured to obtain a mobile phone number in the pre-fetch number request, and search for an access token in an unused state associated with the mobile phone number; a target mask generating module configured to, in a case where the access token in the unused state is not found, determine a risk level of the mobile phone number, and generate a target mask associated with the mobile phone number according to a corresponding mask generation strategy according to the risk level; create target access token information, and return the target access token information and the target mask to the client; a response information generating module configured to, in response to receiving a replacement request of the client, verify access token information in the replacement request, and return response information according to a verification result.

[0013] In a possible implementation, the device further comprises: a prompt information returning module configured to, in a case where the access token in the unused state is found, return prompt information, the prompt information being used to prompt a user to complete a replacement operation that is not completed last time.

[0014] In a possible implementation, the access token further comprises an expired state, and the device further comprises: a state modifying module configured to scan the state of the access token according to a set period, and modify the state of the access token to expired if it is found that the access token in the unused state has timed out.

[0015] In a possible implementation, the target mask generating module is specifically configured to: obtain risk feature information in at least one dimension corresponding to the mobile phone number; a historical risk feature, used to represent a number of times that the mobile phone number is identified to have one or more access tokens in the unused state associated with the mobile phone number in historical login behaviors; a request frequency feature, used to represent a number of pre-fetch number requests of the mobile phone number in a unit time; a replacement ratio feature for representing a ratio of a number of successful pre-fetch number request times and a number of successful replacement request times of the mobile phone number; determine a risk level of the mobile phone number according to the risk feature information.

[0016] In a possible implementation, the target mask generation module is specifically configured to: if the risk level is low risk, determine a first strategy as the target generation strategy; the first strategy is to keep the last four digits of the mobile phone number; if the risk level is medium risk, determine a second strategy as the target generation strategy; the second strategy is to determine the number of tail digits of the mobile phone number based on a time period function; if the risk level is high risk, determine a third strategy as the target generation strategy; the third strategy is to determine a starting position and a continuous length of exposed digits in the mobile phone number based on client information; process the mobile phone number based on the target generation strategy to generate a corresponding target mask.

[0017] In a possible implementation, the target mask generation module is specifically configured to: generate a unique token string as an access token; set an initial state of the access token as unused; establish an association relationship between the access token and the mobile phone number and the target mask; determine access token information carrying the initial state and the association relationship as target access token information.

[0018] In a possible implementation, the response information generation module is specifically configured to: parse the access token information to obtain a state of the access token; if the state of the access token is unused, perform a first operation; the first operation includes updating the state of the access token to used and returning a real mobile phone number associated with the access token to the client; if the state of the access token is not unused, perform a second operation; the second operation includes returning a replacement error information to the client.

[0019] In a third aspect, the present application provides an electronic device, comprising a processor and a memory, the processor is configured to execute a login program stored in the memory to implement the login method in any one of the first aspect.

[0020] In a fourth aspect, the present application provides a storage medium, which stores one or more programs, and the one or more programs are executable by one or more processors to implement the login method in any one of the first aspect.

[0021] Compared with the prior art, the above technical solution provided by the embodiments of the present application has the following advantages: the method provided by the embodiments of the present application, based on the mobile phone number in the pre-fetch number request received by the client, finds the access token in the unused state associated with the mobile phone number; if not found, generates a target mask according to the corresponding mask generation policy according to the risk level of the mobile phone number, and creates target access token information, and returns to the client. In response to receiving the permutation request of the client, the corresponding response information is returned. The pre-fetch number request of the access token in the unused state is blocked, avoiding malicious users from bypassing the permutation request to stockpile access tokens; based on multi-dimensional risk analysis, the mask is dynamically generated in stages, which has the characteristics of unpredictability and non-reusability, avoiding malicious login behavior by bypassing the permutation request through the cache mask. Through the state linkage closed loop and the dynamic mask, a security system of active immunization and adaptive response is constructed, which is non-invasive to benign users and accurately attacks malicious users, realizes the unity of security and convenience, and avoids the problem of malicious avoidance of agents. BRIEF DESCRIPTION OF DRAWINGS

[0022] The accompanying drawings, which are incorporated into and form part of the specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the application.

[0023] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced as follows. Obviously, those skilled in the art can obtain other drawings from these drawings without any creative effort.

[0024] One or more embodiments are exemplarily illustrated by the pictures in the corresponding drawings, which do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, unless otherwise specified. The drawings in the drawings do not constitute a proportional limitation.

[0025] Figure 1 An embodiment flowchart of a login method provided by the embodiments of the present application; Figure 2 An embodiment flowchart of another login method provided by the embodiments of the present application; Figure 3 A whole scheme flowchart of a one-key login method based on dynamic mask and state linkage provided by the embodiments of the present application; Figure 4A pre-fetch number blocking mechanism flowchart of a one-key login method based on dynamic mask and state linkage provided by an embodiment of the application is provided. Figure 5 A permutation state management flowchart of a one-key login method based on dynamic mask and state linkage provided by an embodiment of the application is provided. Figure 6 A risk analysis flowchart of a one-key login method based on dynamic mask and state linkage provided by an embodiment of the application is provided. Figure 7 A dynamic mask generation flowchart of a one-key login method based on dynamic mask and state linkage provided by an embodiment of the application is provided. Figure 8 A structural block diagram of a login device provided by the application is provided. Figure 9 A structural schematic diagram of an electronic device provided by an embodiment of the application is provided. DETAILED DESCRIPTION

[0026] To make the purpose, technical solutions and advantages of the embodiments of the application clearer, the technical solutions in the embodiments of the application will be described clearly and completely below with reference to the drawings in the embodiments of the application. Obviously, the described embodiments are part of the embodiments of the application, rather than all the embodiments of the application. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative work belong to the scope of protection of the application.

[0027] The following disclosure provides many different embodiments or examples for implementing different structures of the application. To simplify the disclosure of the application, the components and settings of specific examples are described below. Of course, they are only examples and the purpose is not to limit the application. In addition, reference numerals and / or letters can be repeated in different examples. Such repetition is for the purpose of simplification and clarity, and does not in itself indicate a relationship between the various embodiments and / or settings being discussed.

[0028] To solve the technical problems of fixed mask mode and pre-fetch number request mechanism in the prior art, causing users to skip permutation operation and maliciously avoid billing verification, the application provides a login method, device, electronic device and storage medium, blocking pre-fetch number requests of access tokens in an unused state, avoiding malicious users from bypassing permutation requests to stockpile access tokens; based on multi-dimensional risk analysis, dynamically generating masks in stages, with unpredictable and non-reusable characteristics, avoiding malicious login behavior by bypassing permutation requests through cache masks. Through state linkage closed loop and dynamic mask, a proactive immune, adaptive response security system is built, which is non-invasive to benign users and accurately attacks malicious users, achieving the unity of security and convenience, while avoiding the malicious avoidance of billing by agents.

[0029] Figure 1 An embodiment flowchart of a login method provided by an embodiment of the present application is applied to an operator server, as shown in Figure 1 The method includes the following steps: Step 101, receiving a pre-fetching number request of a client.

[0030] The client can refer to a mobile application APP (such as a shopping, social APP, etc.) integrated with an agent SDK and an operator SDK on a user mobile terminal, containing a user operation portal, which can be a terminal side carrier for initiating a login request. For example, after a user clicks a one-key login button on a mobile terminal APP interface, the SDK in the client initiates a related request, guides the user to perform a related operation (such as inputting a received related verification code of a login mobile phone number), so as to facilitate the user to successfully one-key login a related application APP.

[0031] The one-key login can be a method for completing login authentication by fetching a number service of an operator server, according to IP and other information of a user mobile terminal, to obtain a user mobile phone number. Its essence is to utilize a unique network identity authentication capability of an operator to realize login authorization of a user with no sense or extremely simple confirmation. Two steps are generally required to complete the one-key login. The first step is pre-fetching a number, that is, the user initiates a one-key login pre-fetching number request through a mobile terminal, and based on an agent SDK and an operator SDK integrated in the client, an access token (i.e., accessCode) corresponding to a related mobile phone number is obtained from an operator server. The second step is replacement, that is, the user initiates a replacement request based on the obtained access token, and the operator server calls a state management module according to the access token, verifies the access token, and returns a corresponding real mobile phone number after verification, so that the user can one-key login a corresponding application APP.

[0032] The access token can refer to a globally unique, temporary string credential generated by the operator server, that is, a mobile phone verification number (for example, "a1b2c3d4e5f6g7h8", "3056", etc.), which is essentially a state carrier. Each access token is bound to its corresponding state, specifically, the state of the access token can be used, unused, expired, etc. Among them, the access token in the unused state indicates that the token has been generated and issued, but has not been used to exchange a real mobile phone number, which is the initial state of the token. The access token in the used state indicates one of the final states of the token, that is, after the user confirms login on the authorization page, the agent SDK initiates a replacement request carrying the token, and after verification by the operator number server, the token state is updated from UNUSED (unused state) to USED (used state), indicating that the login process is complete. The expired state can refer to the token in the UNUSED (unused state) state exceeding the set validity period (such as 30 minutes), which is automatically modified by the system timing scan; after expiration, the token is invalid and cannot be used for replacement, nor can it be determined as unused state by the pre-number query.

[0033] The pre-number request can refer to the first stage request of the one-key login process, which is not to directly obtain a real mobile phone number, but to prepare for subsequent formal login (replacement) and obtain a temporary authorization credential accessCode (access token) and a mobile phone mask for user confirmation.

[0034] In an embodiment, the user triggers a pre-number request through a client APP, and the operator SDK in the client collects necessary device and environment information, encapsulates it into a structured request message, which usually includes an identity, a user IP address, a device identifier, and APP information, and sends the message to a specific API interface of the operator server through a network transmission protocol to ensure transmission security. The network interface layer of the operator server receives the pre-number request sent by the client for preliminary verification and analysis.

[0035] Step 102, obtain the mobile phone number in the pre-number request, and find the access token in the unused state associated with the mobile phone number.

[0036] Step 103, in the case where the access token in the unused state is not found, determine the risk level of the mobile phone number, and generate a target mask associated with the mobile phone number according to the corresponding mask generation strategy according to the risk level; create target access token information, and return the target access token information and the target mask to the client.

[0037] For steps 102-103 described above, the following is uniformly described: Based on the above description of step 101, the user's mobile phone number can be pre-acquired by the client's operator SDK through cellular network information or SMS mobile number identification technology, and reported to the operator server along with the pre-fetch number request.

[0038] In an embodiment, after receiving the pre-fetch number request, the operator server calls the accessCode state management storage table based on the mobile phone number in the pre-fetch number request, queries all access tokens bound to the mobile phone number in the accessCode state management storage table with the mobile phone number as the search key, and filters out tokens with the state UNUSED: if there is at least one, return error code ERR_PENDING_EXCHANGE, which is used to prompt the user to complete the verification of the UNUSED token; if not, generate the corresponding target mask and target access token information and return it to the client.

[0039] The target mask can refer to a processed, partially hidden mobile phone display format. The target access token information can refer to a data structure containing the token itself, its state, and its associated relationship.

[0040] Specifically, the target mask and the target access token information are generated in the following way: first, based on the multi-dimensional risk characteristics, the security risk of the current login pre-fetch number request is evaluated, and a risk level result is output. According to different risk levels, different dynamic mask generation strategies are determined, and the target mask corresponding to the mobile phone number in the current pre-fetch number request is dynamically generated. Then generate a globally unique string as the access token corresponding to the mobile phone number, and determine the state of the access token as unused, establish the structured data of the access token and the mobile phone number, the target mask, the state, etc. with the associated relationship, and take the structured data as the target access token information.

[0041] Exemplarily, the target mask and the target access token information can be encapsulated as JSON structure data, as follows: { "code":200, "data":{ "accessToken":"a1b2c3d4e5f6g7h8", "maskedMobile":"138XXXXXX67" } } The above structured JSON structure data is returned to the client.

[0042] In addition, since the access token also has an expired state, after finding the access token in the unused state, it can be first determined whether the access token in the unused state has exceeded the set time (for example, has exceeded 10 minutes), and if it has exceeded the time, the state of the access token is directly modified to the expired state. In addition to the above scheme, the state of the access token can also be periodically scanned in the pre-fetching stage of the one-key login process, and if it is found that the access token in the unused state has exceeded the time, the state of the access token is modified to the expired state.

[0043] Step 104, in response to receiving the replacement request of the client, verifying the access token information in the replacement request, and returning response information according to the verification result.

[0044] The replacement request can be a second stage request of the one-key login. Its essence is that the client uses the previously obtained access token to redeem the real mobile phone after the user confirms the login. For example, after the user receives the access token returned by the client, the corresponding replacement request is sent to the operator server based on the related operation (such as the fill operation or the copy operation) of the access token. The operator server verifies the access token information in the replacement request of the client, and returns the corresponding response information after the verification is passed.

[0045] In an embodiment, the access token information in the received replacement request is parsed, the state of the access token is determined, if it is not in the unused state or the expired state, an error code is directly returned, and if it is in the unused state, the response information is returned and the unused state is modified to the used state.

[0046] The method provided by the embodiment of the application finds the access token in the unused state associated with the mobile phone based on the mobile phone in the received pre-fetching request of the client, generates a target mask according to the corresponding mask generation strategy according to the risk level of the mobile phone if the access token in the unused state is not found, creates target access token information, and returns to the client. The corresponding response information is returned in response to receiving the replacement request of the client. The pre-fetching request of the access token in the unused state is blocked to avoid malicious users from accumulating access tokens by bypassing the replacement request. The mask is dynamically generated based on multi-dimensional risk analysis, which has the characteristics of unpredictability and non-reusability, and avoids malicious login behavior by bypassing the replacement request through the cache mask. Through the state linkage closed loop and the dynamic mask, a security system of active immunity and adaptive response is constructed, which is non-invasive to benign users and accurately attacks malicious users, realizes the unity of security and convenience, and avoids the malicious avoidance of agents to charge problems.

[0047] Figure 2 The embodiment flowchart of another login method provided by the embodiment of the application is as follows: Figure 1Based on the flow shown, mainly describes how to dynamically generate target mask, create target access token information, see Figure 2 As shown, comprising the following steps: Step 201, receiving the pre-number request of the client.

[0048] Step 202, obtaining the mobile phone number in the pre-number request, and searching for an access token in an unused state associated with the mobile phone number.

[0049] For steps 201-202, see the above Figure 1 Detailed description of related embodiments.

[0050] Step 203, in the case where no access token in an unused state is found, obtaining risk feature information of at least one dimension corresponding to the mobile phone: historical risk feature, used to represent the number of times the mobile phone is identified as having one or more access tokens in an unused state associated with the mobile phone in historical login behavior; request frequency feature, used to represent the number of pre-number requests of the mobile phone in a unit of time; replacement ratio feature, used to represent the ratio of the number of pre-number request successes of the mobile phone to the number of replacement request successes.

[0051] Risk feature information is a multi-dimensional data for determining the login risk of a mobile phone, including historical risk feature, request frequency feature, and replacement ratio feature, which are essentially the core basis for risk level classification.

[0052] The historical risk feature can be the cumulative number of times an access token in an unused state is identified in the historical login process of the current mobile phone, used to reflect the historical behavior of the mobile phone avoiding replacement requests, and the higher the number, the higher the risk level. Its essence is an index for quantifying the historical bad behavior of the mobile phone. It counts the cumulative number of times the mobile phone successfully pre-fetches a number but does not complete replacement (i.e., generates an access token in an unused state) in the past period of time (such as 24 hours). The higher the number, the higher the malicious tendency or abnormal behavior of the number "asking only".

[0053] The request frequency feature is essentially an index for identifying short-term burst attacks or crawling behavior. It counts the total number of pre-number requests initiated by the mobile phone (or associated IP / device) in the current time window (such as 1 minute or 1 hour). An abnormally high frequency is a typical sign of machine operation or malicious attack.

[0054] The replacement ratio feature is essentially an index for evaluating the long-term behavior pattern of the mobile phone. It calculates the ratio of the number of all pre-number successes to the number of all replacement successes of the mobile phone in the historical period (such as 7 days). A ratio that is too low (e.g., less than 20%) indicates that the number is in an abnormal state of "pre-fetching only, not logging in" for a long time.

[0055] In an embodiment, the above risk feature information can be determined from the current count read from the in-memory database, or aggregated from the persistent database or big data platform. Specifically, a counter can be maintained for each mobile phone number in the in-memory database, for example, the counter can be incremented by 1 each time a token becomes expired due to timeout. The request frequency feature and the replacement ratio feature corresponding to each mobile phone number can also be calculated once a day, and the calculation results can be cached in the corresponding cache database for real-time query.

[0056] Step 204, determining the risk level of the mobile phone number according to the risk feature information.

[0057] The risk level can be a security level divided based on the risk feature information, including low, medium and high levels, and is a matching basis for the mask generation strategy. The risk level can be calculated according to the preset scoring rules of the system.

[0058] In an embodiment, the scores of the historical risk feature, the request frequency feature, the replacement ratio feature and other features in the risk feature information are calculated, the scores of the features are weighted and summed to obtain a final comprehensive score, and the risk level is determined according to the comprehensive score.

[0059] For example, for the historical risk feature, if the cumulative number of times of identifying the non-use state access token in the historical login process of the current mobile phone number is 0, it is recorded as 0 points, 1-3 times is recorded as 20 points, and 4 times or more is recorded as 40 points. For the request frequency feature: if the total number of pre-fetch number requests initiated by the mobile phone number in the current time window is less than or equal to 5, it is recorded as 0 points; 6-10 times is recorded as 20 points; and more than 10 times is recorded as 30 points. For the replacement ratio feature, if the ratio of the number of pre-fetch number successes to the total number of replacement successes of the mobile phone number in the historical period is less than or equal to 0.3, it is recorded as 0 points; if 0.3-0.7, it is recorded as 20 points; and more than 0.7, it is recorded as 30 points. The comprehensive score of 0-30 points is recorded as low risk, 31-60 points is recorded as medium risk, and 61-100 points is recorded as high risk. In addition, special rules can be set, if any feature reaches the highest risk threshold (such as the replacement ratio reaches 1 or the request frequency is greater than 20 times), it is directly determined as high risk, without the need for cumulative scoring. Here, only an example is given, and the application embodiments are not limited to the specific determination rules for determining the risk level.

[0060] Step 205, generating a target mask associated with the mobile phone number according to the corresponding mask generation strategy according to the risk level.

[0061] The mask generation strategy can refer to a mask generation rule corresponding to a mobile phone number of different risk levels. The core purpose is to dynamically break the static mapping between the mask and the real mobile phone number, thereby ensuring that the mask is not reusable and unpredictable, while balancing user experience.

[0062] In an embodiment, if the risk level is low risk, a first strategy is determined as the target generation strategy; wherein the first strategy is to retain the last four digits of the mobile phone number; if the risk level is medium risk, a second strategy is determined as the target generation strategy; wherein the second strategy is to determine the number of tail digits of the mobile phone number based on a time period function; if the risk level is high risk, a third strategy is determined as the target generation strategy; wherein the third strategy is to determine the starting position and continuous length of the number in the exposed mobile phone number based on the client information; based on the target generation strategy, the mobile phone number is processed to generate the corresponding target mask.

[0063] For example, assume that a real mobile phone number is 138123422225678, wherein the first four digits are the fixed area code, i.e., the fixed prefix (F), and the total number of digits of the mobile phone number is 15, from the 5th digit to the 15th digit is the variable part. If the user behavior of the above mobile phone number is determined to be good, without abnormal records, and the risk level is low risk, the first strategy is used to dynamically generate the mask, only the last four digits of the above mobile phone number and the fixed prefix are retained, and the final generated target mask is: 1381XXXXXXX5678; if the risk level of the above mobile phone number is medium risk, the second strategy is used to dynamically generate the target mask, and the number of digits to be retained is dynamically determined based on the time period function. Assume that the period T = 600s, the current timestamp timestamp = 1672531200, according to formula (1) time period function, formula (2) reserved digit calculation formula, formula (3) intermediate hidden digit calculation formula, and formula (4) time factor calculation formula, the calculation is as follows: ……… formula (1); ……… formula (2); ……… formula (3); ……… formula (4); wherein R represents the number of retained digits, is a function of time period, q represents the number of intermediate hidden digits, t represents the current time factor corresponding to the current timestamp. The calculation obtains the reserved digit R=3, that is, the last three digits are reserved, and the final target mask is generated as 1381XXXXXXXX678, and the mask is the target mask under the current time (t=0); when t=150s, R=5, the target mask is 1381XXXXXX25678; when t=300s, R=3, the target mask is 1381XXXXXXXX678; that is, the user sees the mask that is dynamically changed at different time points, which makes it impossible for the attacker to establish a stable cache library, and the cached mask is quickly invalidated, avoiding the malicious cache mask behavior of the user.

[0064] Further, if the above mobile phone number is of a high risk level, a third strategy is used to dynamically generate a target mask, and the third strategy determines the exposure position of the corresponding mobile phone number according to the client information, that is, the exposure position of the user's mobile phone number is random. Assuming that the IP of the client is 192.168.1.100; the device ID is device_abc123; the exposure length of the high risk level is set to 2, and the exposure length of the extremely high risk level is set to 3; the number of hidden digits S is calculated according to formula (5) below, the exposure position E is calculated according to formula (6) below, and the number of tail hidden characters Q is calculated according to formula (7) below: ………Formula (5); ………Formula (6); ………Formula (7); Wherein, S represents the number of hidden characters, that is, the number of X; E represents the exposure position, that is, from which position the real mobile phone number starts to be exposed; L is the exposure length, that is, the specific length of the real mobile phone number exposed, which is determined according to the risk level; N represents the total number of digits of the mobile phone number; Q represents the number of tail hidden characters, that is, the number of X at the tail; SHA256() represents a hash algorithm. Assuming that S=2, E=8, L=2, and Q=6 are calculated according to the above formula, the final generated target mask is: 1381X22XXXXXX. When the same user changes the network or the client device, a new target mask is recalculated based on the above related formula, which can ensure that the security of the mobile phone number is extremely high, that is, even if the same mobile phone number is used in different device or network environments, the target mask seen is completely different, which completely destroys the attempt of the attacker to identify the user by caching the mask, even if they steal a mask, they cannot reuse it next time.

[0065] Step 206, creating target access token information.

[0066] The target access token information can be a data structure containing a unique string for the token, its initial state (unused), and its association with the phone number and target mask. Furthermore, the target access token information can be persistently stored in a corresponding database for users to view at any time.

[0067] In one embodiment, a unique token string is generated as an access token; the initial state of the access token is set to unused; an association is established between the access token, the mobile phone number, and the target mask; and the access token information carrying the initial state and the association is determined as the target access token information.

[0068] Step 207: Return the target access token information and target mask to the client, and proceed to step 209.

[0069] In one embodiment, the return path of the target access token information and the target mask can be the operator's number retrieval server, the operator's SDK, the agent's SDK, and the client APP, and the entire process is transmitted through an encrypted interface to prevent data from being tampered with.

[0070] For example, the target access token information and target mask mentioned above can be returned in the following JSON format: { "accessCode":"a7f3b92d...8c1e", "mask":"86-138XXXX1234", "expireTime":"2024-XX-XXXX:XX:XX", "status":"UNUSED" This is merely an example, and the embodiments in this application are not intended to limit the scope of the application.

[0071] Step 208: If an access token in an unused state is found, return a prompt message to remind the user to complete the replacement operation that was not completed last time, and end the process.

[0072] In one embodiment, when an unused access token exists, the operator's number pre-fetching server returns the error code ERR_PENDING_EXCHANGE, along with the message: "Please complete the verification that was not completed last time" (supports multi-language adaptation). After receiving the prompt message, the client displays a pop-up message on the login page, guiding the user to complete the previous verification operation (such as redirecting to the previous login page), and disallowing the initiation of a new number pre-fetching request.

[0073] Step 209: In response to receiving the replacement request from the client, verify the access token information in the replacement request, and return response information based on the verification result.

[0074] The receiving replacement request can refer to that the client initiates a POST request to the operator number server after being authorized by a user, and the agent SDK carries an access token string, and the request parameter contains accessCode, APPID, and device information.

[0075] In an embodiment, in response to receiving the replacement request of the client, the access token information is parsed to obtain the state of the access token; if the state of the access token is unused, a first operation is performed; wherein the first operation comprises: updating the state of the access token to used, and returning the real mobile phone number associated with the access token to the client; if the state of the access token is not unused, a second operation is performed; wherein the second operation comprises: returning a replacement error information to the client.

[0076] For example, the user sees the dynamically generated mobile phone mask (such as 1381X22XXXXXX) on the client login page, confirms that it is correct, and clicks the local number one-key login button. At this time, the agent SDK is triggered, which collects the following information: mobile phone target access token information, application identity information, request timestamp, etc., assembles a structured replacement request, and sends the above data in JSON format to the replacement interface of the operator number server through HTTPS POST request. For example, the JSON format HTTPS POST request is as follows: POST / api / v1 / exchange HTTP / 1.1 Host: carrier-auth-server.com Content-Type: application / json { "accessCode": "a1b2c3d4e5f6", "appId": "com.example.shop", "timestamp": 1672531200000, "signature": "xxxx" }。

[0077] The server parses the replacement request sent by the client to obtain the target access token information, verifies the detailed information of the token, and if the verification finds that the target access token information is in the unused state, the unused state is modified to the used state, and the real mobile phone number is returned to the client. If the verification finds that the target access token information is in the non-unused state, a replacement error information is returned.

[0078] Through Figure 2The related description of the embodiment shown is that the risk level of the mobile phone number corresponds to different mask generation strategies, different masks are dynamically generated, and the non-reusability of the mask is ensured. In addition, by strongly binding the pre-fetch number and the replacement, if there is an unfinished replacement request, the pre-fetch number is not needed, and the agent is avoided from escaping billing by hoarding tokens and skipping replacement requests. Further, the mobile phone numbers are divided into risk levels, the high-risk mobile phone numbers are controlled, the low-risk users are kept for convenient experience, and the login efficiency is ensured. At the same time, the mask and the target access token information are persistently stored, the subsequent abnormal behavior is traced back, and data support is provided for operation optimization.

[0079] In addition, the application also provides an embodiment of a one-key login method based on dynamic mask and state linkage. The following is described in detail from six aspects: overall scheme flow, pre-fetch number blocking mechanism flow, replacement state management flow, risk analysis, and dynamic mask generation.

[0080] Figure 3 An overall scheme flowchart of a one-key login method based on dynamic mask and state linkage provided by the embodiment of the application is shown in Figure 3 As shown, it includes: Step one, the user actively triggers the mobile phone one-key login function on the APP end, and starts the login process. Step two, since the agent SDK has integrated the operator SDK, after triggering the login, the operator SDK automatically carries the identity identifier, the client IP, the APP basic information, and other necessary parameters, and initiates a pre-fetch number request to the operator number server. Step three, after receiving the pre-fetch number request, the operator number server first obtains the user mobile phone number through the related information in the request, and then calls the accessCode state management module to query whether the mobile phone number is associated with an accessCode (access token information) with a state of UNUSED (unused state). Step four, if the query result is that there is an accessCode with the UNUSED state, the operator number server directly returns a specific error code ERR_PENDING_EXCHANGE, prompting that the historical unfinished replacement operation needs to be completed. Step five, if the query result is that there is no accessCode with the UNUSED state, the operator number server generates a dynamic mask according to the corresponding strategy of the risk level, and creates an accessCode with the UNUSED state. Then the accessCode and the dynamic mask are returned to the agent SDK. Step six, after receiving the agent SDK, the APP login authorization page shows dynamic mask, the user checks the mask, confirms login, triggers the agent SDK to carry the accessCode to the operator to send the replacement request to the number server; Step seven, the operator number server calls the state management module to verify the accessCode state in the replacement request; Step eight, if the verification result is that the accessCode state is not UNUSED (i.e. USED or EXPIRED), return the replacement error information; Step nine, if the verification result is that the accessCode state is UNUSED, it is determined to be a normal replacement request, and the state of the accessCode is updated to USED; Step ten, finally, the operator number server returns the user's real mobile phone number to the agent SDK, the APP completes login authentication, and the user logs in successfully.

[0081] Figure 4 A pre-number blocking mechanism flowchart of a one-key login method based on dynamic mask and state linkage provided by the embodiment of the application, as shown in Figure 4 , comprising: Step one, the agent SDK monitors user operations in real time, and starts the pre-number process when it identifies that the user triggers the one-key login function of the mobile phone number; Step two, based on the integrated relationship between the agent SDK and the operator SDK, the operator SDK initiates a pre-number request to the operator number server and synchronously transmits necessary verification parameters; Step three, after receiving the request, the operator number server immediately calls the accessCode state management module, takes the associated mobile phone number as the search key, and queries whether there is an accessCode record with the UNUSED state; Step four, if the state management module queries that there is an UNUSED record, return the existing result to the operator number server; Step five, after receiving the existing result, the operator number server returns a specific error code ERR_PENDING_EXCHANGE to the operator SDK; Step six, the operator SDK parses the error code into a user-understandable prompt text "please complete the last verification", and feeds back to the agent SDK to guide the user to close the loop of the historical incomplete replacement operation; Step seven, if the state management module queries that there is no UNUSED record, return the non-existing result to the operator number server; Step eight, the operator number server generates a dynamic mask matching the mobile phone number based on the risk level corresponding to the mobile phone number, calls a dynamic mask generation strategy, and generates a dynamic mask matching the mobile phone number; Step nine, at the same time, the operator number server generates a unique accessCode corresponding to the pre-number this time, calls a state management module to mark the state of the accessCode as UNUSED, and completes the associated storage; Step ten, the operator number server returns the generated dynamic mask and the accessCode in the UNUSED state to the operator SDK; Step eleven, the operator SDK receives and forwards the two core data to the agent SDK, providing support for subsequent user authorization confirmation and replacement request processes.

[0082] Figure 5 A replacement state management flowchart of a one-key login method based on dynamic mask and state linkage provided by the embodiment of the application, as shown in Figure 5 , includes: Step one, when the system creates an accessCode, it automatically sets its initial state to UNUSED, indicating that the token has not been used and has not triggered a replacement operation; Step two, when the user initiates a new pre-number request, the system will synchronously check whether the existing accessCode associated with the mobile phone number has expired, if it exceeds the preset validity period, the state of the accessCode will be updated from UNUSED (unused) to EXPIRED (expired), and if it does not exceed the time limit, the UNUSED state remains unchanged; Step three, after entering the replacement stage, the system first verifies the current state of the accessCode to be used: if the state is UNUSED, it is determined to be a legal replacement request, and the state of the accessCode is changed to USED; if the state is not UNUSED (i.e., EXPIRED has expired or USED has been used), it is determined to be an invalid request, and an error message is returned directly; Step four, after the state of the accessCode changes to EXPIRED (expired) or USED (used), it becomes the final state, and the system will persistently store the token information of these two states for subsequent query and audit.

[0083] Figure 6 A risk analysis flowchart of a one-key login method based on dynamic mask and state linkage provided by the embodiment of the application, as shown in Figure 6 , includes: Step one, start the risk level determination process, the system calls the risk analysis module, synchronously associates the accessCode state management module and the request log database, and extracts three types of core risk features corresponding to the mobile phone number; Step two, identify the replacement missing feature: through the accessCode state management module query, if it is detected that the mobile phone is put into the history login behavior, there is an accessCode with UNUSED state (only the pre-fetch number is completed without triggering the replacement), mark this feature as a risk associated state; Step three, identify the request frequency feature: count the number of pre-fetch number requests initiated by the mobile phone (or associated IP / device) within a unit of time, if the frequency exceeds the preset threshold, determine that there is an abnormal risk of batch acquisition of masks; Step four, identify the replacement ratio feature: rely on the historical data of the accessCode state management module, calculate the ratio of the number of pre-fetch number success and the number of replacement success of the mobile phone, if the ratio deviates from the normal range, mark it as a ratio anomaly; Step five, risk level comprehensive judgment: combine the risk degree of the above three types of features, calculate the comprehensive score by preset scoring rules, and divide the mobile phone into three levels of low risk, medium risk or high risk; Step six, match dynamic mask generation strategy: according to the final determined risk level, automatically select the corresponding strategy to generate mobile phone mask. Specifically, low risk uses fixed four-bit retention strategy, medium risk uses time period dynamic adjustment retention bit number strategy, and high risk uses location random exposure strategy based on device ID and IP.

[0084] Figure 7 A dynamic mask generation flowchart of a one-key login method based on dynamic mask and state linkage provided by the embodiment of the application is shown in Figure 7 , which includes: Step one, start the mobile phone mask generation process, first extract the fixed prefix of the mobile phone (denoted as F), which is the combination of the area code and the first three digits of the mobile phone, and determine the total number of mobile phone digits (denoted as N); Step two, call the risk analysis module, combine the accessCode state management module and request log data, and comprehensively judge the replacement evasion risk of the mobile phone, output the level result of low risk, medium risk or high risk; Step three, according to the determined risk level, automatically match the corresponding mobile phone mask generation strategy, and determine the core generation logic and algorithm direction; Step four, according to the selected generation strategy, adjust the key parameters of the mask generation algorithm. Low risk strategy does not need additional adjustment, medium risk strategy configures time period related parameters, and high risk strategy inputs associated parameters such as client IP and device identifier (DeviceID); Step five, execute algorithm calculation to generate the final mask, the specific logic is as follows: Low risk strategy: directly retain the last four digits of the mobile phone to ensure user identification experience; Medium risk strategy: first calculate the time factor t by formula (4), then substitute it into the time period function shown in formula (1), and finally determine the tail number of reserved bits R by formula (2), the mask format is M=F+‘X’x(N-5-R)+tail number R bits of digits, and the number of reserved bits is dynamically changed; High risk strategy: calculate the number of hidden characters S by formula (5), determine the exposure length L according to the risk level (high risk L=2, very high risk L=3), extract the L digits of the mobile phone from the position 6+S as the exposure section E1, and the mask format is M=F+‘X’xS+E1+‘X’x(N-5-S-L), which realizes the randomization of the exposure position.

[0085] For the above example of dynamic generation of related masks, see the related description of the above Figure 2 Embodiments.

[0086] Through the above description of the embodiments, based on the pre-number blocking mechanism, the accessCode in the unused state is checked, and the closed-loop history replacement process is forced to prevent the malicious behavior of agents hoarding tokens and skipping replacement, thereby completely solving the security vulnerability caused by the separation of pre-number and replacement in the prior art. Dynamic mask generation based on risk level, low-risk scenario retains the familiar last four digits display form, medium-risk dynamically adjusts the number of reserved bits by time period, high-risk randomly determines the exposure position combined with device ID and IP, completely breaks the static mapping relationship between mask and real mobile number, makes the old mask cached by the merchant completely invalid, greatly improves the security of user information, and effectively resists batch acquisition, malicious matching and other attack behaviors.

[0087] Further, the risk grading strategy realizes the balance between security and convenience, and the low-risk user does not need to adapt to the new mask form, and maintains the smoothness of the original login experience. The dynamic mask generation in medium and high risk scenarios does not require additional user operation, and only needs to be optimized by the background algorithm to realize security enhancement, which has low user perception, meets the security control demand, and avoids the influence of excessive protection on login efficiency.

[0088] Figure 8 A structural block diagram of a login device is provided for the present application, and the device comprises: A pre-number request module 81 is configured to receive a pre-number request of a client; An access token searching module 82 is configured to obtain a mobile number in the pre-number request, and search for an access token in an unused state associated with the mobile number; The target mask generation module 83 is configured to, in a case where the access token in the unused state is not found, determine a risk level of the mobile phone number, and generate a target mask associated with the mobile phone number according to a corresponding mask generation strategy according to the risk level; create target access token information, and return the target access token information and the target mask to the client; The response information generation module 84 is configured to, in response to receiving a replacement request of the client, verify access token information in the replacement request, and return response information according to a verification result.

[0089] In a possible implementation, the apparatus further includes: The prompt information return module is configured to, in a case where the access token in the unused state is found, return prompt information, where the prompt information is used to prompt a user to complete a last incomplete replacement operation.

[0090] In a possible implementation, the access token further includes an expired state, and the apparatus further includes: The state modification module is configured to scan a state of the access token according to a set period, and modify the state of the access token to the expired state if the access token in the unused state is found to have timed out.

[0091] In a possible implementation, the target mask generation module 83 is specifically configured to: obtain risk feature information in at least one dimension corresponding to the mobile phone number, including: a historical risk feature, used to represent a number of times that the mobile phone number is identified to have one or more access tokens in the unused state associated with the mobile phone number in historical login behaviors; a request frequency feature, used to represent a number of pre-number request times of the mobile phone number in a unit time; a replacement ratio feature, used to represent a ratio of a number of pre-number request success times of the mobile phone number to a number of replacement request success times of the mobile phone number; and determine a risk level of the mobile phone number according to the risk feature information.

[0092] In a possible implementation, the target mask generation module 83 is specifically configured to: if the risk level is a low risk, determine a first strategy as a target generation strategy; the first strategy is to retain last four digits of the mobile phone number; if the risk level is a medium risk, determine a second strategy as the target generation strategy; the second strategy is to determine a number of tail number digits of the mobile phone number based on a time period function; If the risk level is high risk, a third strategy is determined as a target generation strategy; wherein the third strategy is to determine the starting position and continuous length of exposing the numbers in the mobile phone number based on the client information; Based on the target generation strategy, the mobile phone number is processed to generate a corresponding target mask.

[0093] In a possible implementation, the target mask generation module 83 is specifically configured to: generate a unique token string as an access token; set the initial state of the access token as unused; establish an association relationship between the access token and the mobile phone number and the target mask; determine access token information carrying the initial state and the association relationship as target access token information.

[0094] In a possible implementation, the response information generation module 84 is specifically configured to: parse the access token information to obtain the state of the access token; if the state of the access token is unused, perform a first operation; wherein the first operation includes: updating the state of the access token to used, and returning the real mobile phone number associated with the access token to the client; if the state of the access token is not unused, perform a second operation; wherein the second operation includes: returning a substitution error message to the client.

[0095] As shown in Figure 9 The embodiments of the present application provide an electronic device, which includes a processor 111, a communication interface 112, a memory 113 and a communication bus 114, wherein the processor 111, the communication interface 112 and the memory 113 complete mutual communication through the communication bus 114, The memory 113 is used to store a computer program; In an embodiment of the present application, the processor 111 is used to execute the program stored in the memory 113, and realizes the login method provided by any one of the preceding method embodiments, including: receiving a pre-fetching number request of a client; obtaining a mobile phone number in the pre-fetching number request, and finding an access token in an unused state associated with the mobile phone number; if no access token in the unused state is found, determining a risk level of the mobile phone number, and generating a target mask associated with the mobile phone number according to a corresponding mask generation strategy according to the risk level; creating target access token information, and returning the target access token information and the target mask to the client; In response to receiving the permutation request of the client, verifying the access token information in the permutation request, and returning response information according to a verification result.

[0096] The embodiments of the present application further provide a computer readable storage medium, which stores a computer program. The computer program is executed by a processor to implement the steps of the login method provided by any one of the preceding method embodiments.

[0097] The apparatus embodiments described above are merely illustrative, wherein the units described as separate components can or can not be physically separate, and the components displayed as units can or can not be physical units, i.e., can be located in one place, or can be distributed on multiple network units. Part or all of the modules can be selected according to actual needs to achieve the purpose of the embodiments.

[0098] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a general hardware platform, and of course can also be implemented by hardware. Based on such understanding, the above technical solutions can be embodied in the form of a software product, which can be stored in a computer readable storage medium, such as a ROM / RAM, a magnetic disk, an optical disk, etc., and includes a plurality of instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute the methods described in each embodiment or some parts of the embodiments.

[0099] It should be understood that the terms used herein are for the purpose of describing particular example embodiments only and are not intended to be limiting. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms "comprises", "comprising", "includes", "including" and the like are to be construed as in the manner set out in the United States Court of Appeals for the Federal Circuit in IN RE WOHL, 903 F.2D 1561, 1572 (1990), which is incorporated herein by reference. The method steps, processes, and operations described herein are not to be construed as necessarily requiring their performance in the particular order in which they are described, unless specifically identified as such. It is also to be understood that additional or alternative steps can be employed.

[0100] The foregoing detailed description of the application has been presented for purposes of illustration and description. Various modifications and changes can be made to these embodiments without departing from the spirit and scope of the application. It is intended that the scope of the application should not be limited by the particular representative embodiments described above.

Claims

1. A login method, characterized in that, The method includes: Receive the client's pre-fetch number request; Obtain the mobile phone number in the pre-fetch request, and find the access token in an unused state associated with the mobile phone number; If no access token in an unused state is found, determine the risk level of the mobile phone number, and generate a target mask associated with the mobile phone number according to the risk level and the corresponding mask generation strategy; create target access token information, and return the target access token information and the target mask to the client; In response to receiving a replacement request from a client, the system verifies the access token information in the replacement request and returns response information based on the verification result.

2. The method according to claim 1, characterized in that, The method further includes: If an access token that is not in use is found, a prompt message is returned to remind the user to complete the replacement operation that was not completed last time.

3. The method according to claim 1, characterized in that, The access token also includes an expired status, and the method further includes: The status of the access token is scanned according to the set period. If an access token in an unused state is found to have expired, the status of the access token is changed to expired.

4. The method according to claim 1, characterized in that, Determining the risk level of the mobile phone number includes: Obtain risk characteristic information corresponding to the mobile phone number in at least one of the following dimensions: Historical risk characteristics are used to indicate the number of times the mobile number has been identified as having one or more unused access tokens associated with the mobile number in historical login behavior; The request frequency feature is used to represent the number of times the mobile number is requested to retrieve a number within a unit of time. The replacement ratio feature is used to represent the ratio of the number of successful number retrieval requests to the number of successful replacement requests for the mobile number. Based on the risk characteristic information, the risk level of the mobile phone number is determined.

5. The method according to claim 1, characterized in that, The step of generating a target mask associated with the mobile phone number according to the risk level and the corresponding mask generation strategy includes: If the risk level is low risk, then the first strategy is determined as the target generation strategy; wherein, the first strategy is to retain the last four digits of the mobile phone number; If the risk level is medium risk, then the second strategy is determined as the target generation strategy; wherein, the second strategy is to determine the number of digits to retain the last few digits of the mobile phone number based on a time period function; If the risk level is high risk, then the third strategy is determined as the target generation strategy; wherein, the third strategy is to determine the starting position and continuous length of the digits in the exposed mobile phone number based on the client information; Based on the target generation strategy, the mobile phone number is processed to generate a corresponding target mask.

6. The method according to claim 1, characterized in that, The creation of the target access token information includes: Generate a unique token string as the access token; Set the initial state of the access token to unused; Establish an association between the access token, the mobile phone number, and the target mask; The access token information carrying the initial state and the association is determined as the target access token information.

7. The method according to claim 1, characterized in that, The process verifies the access token information in the replacement request and returns response information based on the verification result, including: Parse the access token information to obtain the access token status; If the access token is in an unused state, then the first operation is performed; wherein the first operation includes: updating the access token to a used state and returning the real mobile phone number associated with the access token to the client; If the access token is in a non-unused state, then a second operation is performed; wherein the second operation includes: returning a substitution error message to the client.

8. A login device, characterized in that, The device includes: The number retrieval request module is used to receive number retrieval requests from clients; The access token lookup module is used to obtain the mobile phone number in the pre-fetch number request and look up the access token in an unused state associated with the mobile phone number; The target mask generation module is used to determine the risk level of the mobile phone number when no unused access token is found, and generate a target mask associated with the mobile phone number according to the risk level and the corresponding mask generation strategy; create target access token information, and return the target access token information and the target mask to the client; The response information generation module is used to respond to a replacement request received from a client, verify the access token information in the replacement request, and return response information based on the verification result.

9. An electronic device, characterized in that, include: A processor and a memory, the processor being configured to execute a hybrid electric vehicle control program stored in the memory to implement the login method according to any one of claims 1-7.

10. A storage medium, characterized in that, The storage medium stores one or more programs, which can be executed by one or more processors to implement the login method according to any one of claims 1-7.

Images