Verification code checking method and device, storage medium and computer device

Abstract

The verification code verification method and device, the storage medium and the computer device provided by the application, the server can verify whether the first check bit corresponding to the verification code input result is contained in the first burying point information and whether the first check bit is abnormal, so as to judge whether the current verification operation is an abnormal operation. For example, when the first check bit is not contained in the first burying point information or the first check bit is abnormal, it can be judged that the current verification operation is an abnormal operation, and then the user can be intercepted in the form of direct interception, or the user can be intercepted when the user requests to enter a specific link, thereby effectively preventing malicious attacks by hackers. In addition, the first check bit in the application is hidden in the first burying point information, so that the existence of the check bit function is not easy to be found by hackers when they carry out malicious attacks, thereby confusing the vision and hearing of the hackers to a certain extent, and further improving the anti-risk ability of the verification mechanism.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and in particular to a verification code verification method, apparatus, storage medium, and computer equipment. Background Technology

[0002] Currently, in order to ensure information security, most applications have introduced verification mechanisms, such as CAPTCHAs. CAPTCHAs, as a public, fully automated program that distinguishes between humans and machines, are widely used in various applications.

[0003] However, existing verification mechanisms are at high risk of being cracked. For example, hackers can directly call the server interface and pass in the verification code input result through the server interface. When the server interface requires front-end data (such as timestamps, device numbers, behavioral tracking points, etc.), they can also forge the front-end data and pass the verification by using the forged verification code input result and the front-end data.

[0004] Therefore, it is necessary to study a verification mechanism that can prevent malicious attacks by hackers. Summary of the Invention

[0005] The purpose of this invention is to at least solve one of the aforementioned technical defects, particularly the lack of a verification mechanism in the prior art that can prevent malicious attacks by hackers.

[0006] This invention provides a verification code verification method, the method comprising:

[0007] Obtain the verification code input result sent by the client and the first tracking point information;

[0008] The verification result is obtained by verifying whether the first embedded information contains a first verification bit corresponding to the verification code input result and whether the first verification bit is abnormal.

[0009] The verification code input result is validated based on the verification result.

[0010] Optionally, the verification code input result is validated based on the verification result, including:

[0011] If the first embedded information does not contain the first verification bit corresponding to the verification code input result.

[0012] Alternatively, the first embedded information may contain a first verification bit corresponding to the verification code input result, and the first verification bit may be abnormal.

[0013] Therefore, there is no need to verify the input result of the verification code or intercept the verification operation of the user logging into the client.

[0014] Optionally, the verification code input result is validated based on the verification result, including:

[0015] If the first embedded information does not contain the first verification bit corresponding to the verification code input result.

[0016] Alternatively, the first embedded information may contain a first verification bit corresponding to the verification code input result, and the first verification bit may be abnormal.

[0017] The system then uses a preset verification code answer to verify the verification code input result, and returns a verification successful instruction to the client when the verification code input result is correct;

[0018] After successful verification, obtain the request instruction triggered by the user on the client to enter a specific stage, and the second embedded point information corresponding to the request instruction;

[0019] When the user information in the second tracking information corresponds to the user information in the first tracking information, the user's operation to enter the specific stage is intercepted.

[0020] Optionally, the step of verifying whether the first embedded information contains a first check bit corresponding to the verification code input result, and whether the first check bit is abnormal, includes:

[0021] The parameters contained in the first embedded information are parsed, and the parsing results are used to determine whether the first embedded information contains a first verification bit corresponding to the verification code input result.

[0022] If included, the verification code input result is converted according to the conversion method agreed upon with the client to obtain the second verification bit, and the first verification bit is verified to be abnormal based on the second verification bit.

[0023] Optionally, the step of converting the verification code input result according to the conversion method agreed upon with the client to obtain the second verification bit includes:

[0024] Based on the verification code type corresponding to the verification code input result, the verification code input result is converted into the corresponding number and then merged;

[0025] The merged numbers are calculated according to a preset calculation method to obtain a number of preset length, and the number of preset length is used as the second check digit.

[0026] Optionally, verifying whether the first check bit is abnormal based on the second check bit includes:

[0027] Compare the second check bit with the first check bit;

[0028] Verify whether the first check bit is abnormal based on the comparison results.

[0029] Optionally, before obtaining the verification code input result sent by the client and the first tracking information, the method further includes:

[0030] Receive the verification code retrieval request sent by the client and the corresponding third-party tracking information;

[0031] Determine whether the third embedded information meets the preset verification code generation rules;

[0032] If the conditions are met, the corresponding verification code generation parameters are determined based on the verification code generation rules.

[0033] The verification code generation parameters are returned to the client so that the client can generate the corresponding verification code based on the verification code generation parameters.

[0034] The present invention also provides a verification code verification device, comprising:

[0035] The data receiving module is used to obtain the verification code input result sent by the client and the first embedded point information;

[0036] The verification bit verification module is used to verify whether the first embedded information contains a first verification bit corresponding to the verification code input result, and whether the first verification bit is abnormal, and to obtain the verification result.

[0037] The verification code verification module is used to verify the verification code input result based on the verification result.

[0038] The present invention also provides a storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the verification code verification method as described in any of the above embodiments.

[0039] The present invention also provides a computer device, comprising: one or more processors, and a memory;

[0040] The memory stores computer-readable instructions, which, when executed by the one or more processors, perform the steps of the verification code verification method as described in any of the above embodiments.

[0041] As can be seen from the above technical solutions, the embodiments of the present invention have the following advantages:

[0042] The verification code verification method, apparatus, storage medium, and computer equipment provided by this invention allow the server to verify whether the first verification bit corresponding to the verification code input result sent by the client and the first tracking information are present in the first tracking information, and whether the first verification bit is abnormal. The server can then verify the verification code input result based on this verification result. In this application, the server can verify whether the first tracking information contains the first verification bit corresponding to the verification code input result, and whether the first verification bit is abnormal, thereby determining whether the verification operation is abnormal. For example, if the first tracking information does not contain the first verification bit, or the first verification bit is abnormal, the verification operation can be determined to be abnormal. This allows for direct interception of the user, or interception when the user requests to enter a specific stage, effectively preventing malicious attacks by hackers. Furthermore, the first verification bit in this application is hidden within the first tracking information, making it difficult for hackers to detect the existence of the verification bit function during malicious attacks, thus confusing hackers to some extent and further improving the verification mechanism's resilience. Attached Figure Description

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

[0044] Figure 1 A flowchart illustrating a verification code verification method provided in an embodiment of the present invention;

[0045] Figure 2 This is a schematic diagram of the verification code verification process provided in an embodiment of the present invention;

[0046] Figure 3 This is a schematic diagram of the structure of a verification code verification device provided in an embodiment of the present invention;

[0047] Figure 4 This is a schematic diagram of the internal structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0048] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0049] Existing verification mechanisms are at high risk of being cracked. For example, hackers can directly call the server interface and pass in the verification code input result through the server interface. When the server interface requires front-end data (such as timestamps, device numbers, behavioral tracking points, etc.), they can also forge the front-end data and pass the verification by using the forged verification code input result and the front-end data.

[0050] Based on this, this application proposes the following technical solution, as detailed below:

[0051] In one embodiment, such as Figure 1 As shown, Figure 1 This is a flowchart illustrating a verification code verification method provided by an embodiment of the present invention; the present invention provides a verification code verification method, the method including:

[0052] S110: Obtain the verification code input result sent by the client and the first tracking point information.

[0053] In this step, when a user logs into a client and opens its front-end page, a verification mechanism is introduced in the application corresponding to the client. This mechanism allows the user to perform actions such as login, registration, or password retrieval on the front-end page. Based on the user's actions, the client requests verification code generation parameters from the server and generates the corresponding verification code. The client can then display this verification code on the front-end page for the user to input. When the client receives the user's input verification code, it can upload it to the server for further processing.

[0054] It is understood that the "client" in this application refers to an application that provides local services to customers in contrast to a server. Commonly used clients include web browsers used for the World Wide Web, email clients for sending and receiving emails, clients that provide consumption services, and instant messaging client software. For different types of clients, corresponding services, such as database services, email services, and consumption services, can be provided through corresponding servers and service programs on the network. This establishes a specific communication connection between the client and the server, thereby ensuring the normal operation of the application.

[0055] The CAPTCHA generation parameters in this application refer to the necessary parameters when generating CAPTCHAs, such as CAPTCHA type and template ID. The CAPTCHA here refers to a public, fully automated program that distinguishes real users from bots. The CAPTCHA types in this application include, but are not limited to, image CAPTCHAs, question CAPTCHAs, click-based CAPTCHAs, and direct interception.

[0056] Furthermore, in order to reduce the risk of the verification mechanism being cracked, this application allows the client to send the first tracking information corresponding to the current verification code input result, such as timestamp, device number, behavior tracking information, etc., to the server when the client sends the verification code input result. This allows the server to determine the risk level of the current verification code input result based on the first tracking information.

[0057] It is understandable that the first tracking information here refers to the tracking data collected by the tracking component in the client that is related to user information, user behavior, device status, etc. when the user enters the verification code. For example, the mobile phone number corresponding to the user who enters the verification code, the user's behavior trajectory on the current page, and the device IP and IP device location corresponding to the device logged in by the user's client.

[0058] S120: Verify whether the first embedded information contains a first verification bit corresponding to the verification code input result, and whether the first verification bit is abnormal, and obtain the verification result.

[0059] In this step, after obtaining the verification code input result sent by the client and the first tracking information through S110, the server can verify whether the first tracking information contains the first check bit corresponding to the verification code input result, and whether the first check bit is abnormal, and obtain the corresponding verification result.

[0060] Generally, in this application, before the client uploads the verification code input result and the first tracking information to the server, in order to ensure the security of the verification process, the client and the server can agree in advance on the existence of the verification bit and the specific conversion method of the verification bit, and then convert the current verification code input result to be sent according to the pre-agreed conversion method to obtain the corresponding verification bit.

[0061] Furthermore, in order to further ensure the secure transmission of the verification bit and prevent it from being forged by hackers, this application can hide the transformed verification bit in the first tracking information and upload it to the server along with the first tracking information. In this way, even if a hacker knows that the first tracking information is required when sending the verification code input result, they will not be able to forge the verification bit hidden in the first tracking information.

[0062] Furthermore, the conversion methods for verification codes in this application are generally divided into two types: explicit conversion and implicit conversion. Explicit conversion is a type conversion that requires writing code to complete. This type conversion may result in a loss of precision, so the corresponding code must be written, and the type conversion should only be performed if this loss can be tolerated. Implicit conversion is an automatic type conversion, which does not require writing code and is completed automatically by the system. Since such type conversions are frequent in actual development, the Java language was not designed with syntax for this operation; instead, it is handled automatically by the JVM.

[0063] In order to save research and development costs and further improve the conversion accuracy of the verification bit, this application can use an implicit conversion method to convert the verification code input result into the corresponding verification bit, and use the verification bit to perform the corresponding verification operation.

[0064] For example, in this application, the server can verify whether the user in the client that is currently receiving the verification code input result and the first tracking information is an abnormal user based on whether the first tracking information contains a first check bit corresponding to the verification code input result. Alternatively, if the first tracking information contains a first check bit, the server can verify whether the first check bit is abnormal, thereby determining whether the user in the client that is currently receiving the verification code input result and the first tracking information is an abnormal user.

[0065] Understandably, in this application, the client and server agree beforehand that when sending the verification code input result and the first tracking information, the checksum corresponding to the verification code input result will be hidden in the first tracking information and sent to the server together to ensure the security of the verification process. When the server receives the first tracking information, it can verify whether the first tracking information contains the first checksum corresponding to the verification code input result. If it does not contain it, it indicates that the currently logged-in client user is not a legitimate user; if it does contain it, it indicates that the currently logged-in client user is highly likely to be a legitimate user. However, to prevent hackers from forging the checksum, further judgment can be made by checking whether the first checksum is abnormal. If the first checksum is abnormal, it can be confirmed that the currently logged-in client user is not a legitimate user.

[0066] S130: Verify the verification code input result based on the verification result.

[0067] In this step, S120 verifies whether the first embedded information contains a first verification bit corresponding to the verification code input result, and whether the first verification bit is abnormal. After obtaining the corresponding verification result, the server can verify the verification code input result based on the verification result, thereby determining the response method to the request operation triggered by the currently logged-in client user.

[0068] For example, if the first verification bit is not included in the first tracking information, or if the first verification bit is abnormal, the user currently logging into the client can be identified as an abnormal user. For the current operation of an abnormal user, even if the input of the verification code is correct, the server can directly intercept it based on the verification result of the first verification bit to prevent the user from entering the next step.

[0069] Furthermore, in order to confuse hackers, this application may not take any defensive measures at the current verification code stage, but may intercept the user's operation when the user triggers a request command in a subsequent specific stage. This can effectively protect the currently set verification bit logic and prevent hackers from finding the verification bit logic and performing targeted reverse engineering.

[0070] In the above embodiments, after the server obtains the verification code input result and the first tracking information sent by the client, it can verify whether the first tracking information contains a first check bit corresponding to the verification code input result, and whether the first check bit is abnormal, and obtain the verification result. Then, the verification code input result can be verified according to the verification result. In this application, the server can verify whether the first tracking information contains a first check bit corresponding to the verification code input result, and whether the first check bit is abnormal, so as to determine whether the current verification operation is an abnormal operation. For example, if the first tracking information does not contain a first check bit, or the first check bit is abnormal, it can be determined that the current verification operation is an abnormal operation. Then, the user can be intercepted directly, or the user can be intercepted when requesting to enter a specific stage, thereby effectively preventing malicious attacks by hackers. In addition, the first check bit in this application is hidden in the first tracking information, making it difficult for hackers to discover the existence of the check bit function when carrying out malicious attacks, thereby confusing hackers to a certain extent and further improving the risk resistance of the verification mechanism.

[0071] In one embodiment, verifying the verification code input result based on the verification result in step S130 may include:

[0072] S131: If the first tracking information does not contain a first verification bit corresponding to the verification code input result; or, the first tracking information contains a first verification bit corresponding to the verification code input result, and the first verification bit is abnormal.

[0073] S132: Then there is no need to verify the verification code input result and intercept the verification operation of the user logging into the client.

[0074] In this embodiment, since the client and the server have agreed in advance that when sending the verification code input result and the first embedded information, the verification bit corresponding to the verification code input result will be hidden in the first embedded information and sent to the server together, the security of the verification process is guaranteed.

[0075] Therefore, when the server receives the first tracking information, it can verify whether the first tracking information contains the first check bit corresponding to the verification code input result. If it does not contain it, it indicates that the user currently logging in is an abnormal user; if it contains it, it indicates that the user currently logging in is most likely a normal user. However, in order to prevent hackers from forging the check bit, further judgment can be made by checking whether the first check bit is abnormal. If the first check bit is abnormal, it can be confirmed that the user currently logging in is an abnormal user.

[0076] When the first tracking information does not contain the first checksum, or contains the first checksum but the first checksum is abnormal, the user currently logged in can be identified as an abnormal user. For the current operation of an abnormal user, the server can not verify the input result of the verification code and directly intercept the verification operation of the user logged in, such as returning a "direct intercept" instruction, so that the client can intercept the user currently logged in according to the instruction to prevent malicious attacks.

[0077] In one embodiment, verifying the verification code input result based on the verification result in step S130 may include:

[0078] S141: If the first tracking information does not contain a first verification bit corresponding to the verification code input result; or, if the first tracking information contains a first verification bit corresponding to the verification code input result, the first verification bit is abnormal.

[0079] S142: The input result of the verification code is verified using the preset verification code answer, and when the input result of the verification code is correct, a verification success instruction is returned to the client.

[0080] S143: Obtain the request instruction triggered by the user on the client after successful verification to enter a specific stage, and the second embedded point information corresponding to the request instruction.

[0081] S144: When the user information in the second tracking information corresponds to the user information in the first tracking information, the user's operation to enter the specific stage is intercepted.

[0082] In this embodiment, since the client and the server have agreed in advance that when sending the verification code input result and the first embedded information, the verification bit corresponding to the verification code input result will be hidden in the first embedded information and sent to the server together, the security of the verification process is guaranteed.

[0083] Therefore, when the server receives the first tracking information, it can verify whether the first tracking information contains the first check bit corresponding to the verification code input result. If it does not contain it, it indicates that the user currently logging in is an abnormal user; if it contains it, it indicates that the user currently logging in is most likely a normal user. However, in order to prevent hackers from forging the check bit, further judgment can be made by checking whether the first check bit is abnormal. If the first check bit is abnormal, it can be confirmed that the user currently logging in is an abnormal user.

[0084] When the first tracking information does not contain the first checksum, or contains the first checksum but the first checksum is abnormal, the user currently logged into the client can be identified as an abnormal user. For the current operation of an abnormal user, this application can not take any defensive measures at the current verification code stage. However, after the current verification is passed, when the user triggers the request instruction to enter a specific stage on the client, the user's operation can be intercepted. This can effectively protect the currently set checksum logic and prevent hackers from finding the checksum logic and performing targeted reverse engineering.

[0085] Furthermore, to ensure that the intercepted users are not legitimate users and to guarantee the needs of legitimate users, this application verifies whether the first verification bit is included in the first tracking information and whether the first verification bit is abnormal. After obtaining the verification result, the verification result can be associated with the current user information, such as associating the verification result with the current device number or mobile phone number. When a user triggers a request command to enter a specific stage, the user information in the second tracking information corresponding to the current request command can be used to determine whether the currently logged-in client user is the user associated with the verification result. If so, the request command triggered by the user can be responded to based on the associated verification result.

[0086] For example, when it is determined that the user currently logged into the client is the user associated with the verification result, if the verification result does not contain the first checksum in the first tracking information, or contains the first checksum but the first checksum is abnormal, the operation of the user entering a specific stage can be intercepted, thereby effectively preventing the user from entering the next stage and effectively protecting the currently set checksum logic.

[0087] In this application, the specific step refers to the next business process after the user performs a verification operation on the client and passes the verification. This specific step includes, but is not limited to, key steps such as adding to the shopping cart, checkout, or submitting the order.

[0088] In one embodiment, verifying whether the first embedded information contains a first verification bit corresponding to the verification code input result, and whether the first verification bit is abnormal, in step S120 may include:

[0089] S121: Analyze the parameters contained in the first embedded information to determine whether the first embedded information contains a first verification bit corresponding to the verification code input result.

[0090] S122: If included, the verification code input result is converted according to the conversion method agreed with the client to obtain the second verification bit, and the first verification bit is verified as abnormal based on the second verification bit.

[0091] In this embodiment, when determining whether the first tracking information contains a first check bit, the parameters contained in the first tracking information can be parsed to analyze the specific content corresponding to each parameter, or to analyze the parameter name corresponding to each parameter. If the first check bit corresponding to the verification code input result is found, it indicates that the current first tracking information contains a first check bit. If the first check bit corresponding to the verification code input result is not found after parsing all the parameters in the first tracking information, it indicates that the current first tracking information does not contain a first check bit.

[0092] Furthermore, if the first tracking information contains a first verification bit, in order to verify whether the first verification bit is abnormal, this application can convert the verification code input result that is sent together with the client according to the conversion method agreed with the client to obtain a second verification bit, and use the second verification bit to verify whether the first verification bit is abnormal.

[0093] In one embodiment, S122, converting the verification code input result according to the conversion method agreed upon with the client to obtain the second verification bit, may include:

[0094] S1221: Based on the verification code type corresponding to the verification code input result, convert the verification code input result into the corresponding number and then merge them.

[0095] S1222: Calculate the merged numbers according to the preset calculation method to obtain a number of preset length, and use the number of preset length as the second check bit.

[0096] In this embodiment, when the server determines whether the first verification bit is abnormal, it can convert the verification code input result that is sent along with the client according to the conversion method agreed with the client to obtain the second verification bit, and use the second verification bit to verify whether the first verification bit is abnormal.

[0097] Specifically, when converting the verification code input result that is sent along with the client according to the conversion method agreed upon with the client, the verification code input result can be converted into the corresponding number according to the verification code type corresponding to the current verification code input result. The converted numbers are then merged. Then, the merged numbers can be calculated according to the preset calculation method to obtain a number of preset length. This number of preset length can be used as the second verification bit.

[0098] For example, firstly, based on the verification code type corresponding to the verification code input result, the verification code input result can be converted into corresponding characters, each character being a1, a2, a3, a4, etc. Then, each character can be converted into a corresponding number. Next, each number is merged and subjected to a certain obfuscation calculation to generate a fixed-length number. This fixed-length number can then be used as the second check digit corresponding to the current verification code input result.

[0099] It is understandable that, since the client and server agree on the conversion method of the verification bit in advance, the client can obtain the first verification bit in the same way as the server after obtaining the current verification code input result, which will not be elaborated here.

[0100] Furthermore, the verification bit logic in this application can be updated periodically. The server can send the updated verification bit logic to the corresponding client so that the client can synchronize and update its local verification bit logic, thereby further strengthening the risk resistance capability of the verification mechanism.

[0101] In one embodiment, verifying whether the first check bit is abnormal based on the second check bit in S122 may include:

[0102] S1223: Compare the second check bit with the first check bit.

[0103] S1224: Verify whether the first check bit is abnormal based on the comparison results.

[0104] In this embodiment, after the server obtains the second verification bit according to the conversion method agreed upon with the client, it can use the second verification bit to verify whether the first verification bit is abnormal.

[0105] Specifically, the second check bit can be compared with the first check bit. If the second check bit is the same as the first check bit, it means that the first check bit is normal. If the second check bit is different from the first check bit, it means that the first check bit is abnormal.

[0106] In one embodiment, before obtaining the verification code input result sent by the client and the first embedded information in S110, the following may also be included:

[0107] S101: Receives the verification code retrieval request sent by the client and the corresponding third-party tracking information.

[0108] S102: Determine whether the third embedded information meets the preset verification code generation rules.

[0109] S103: If satisfied, determine the corresponding verification code generation parameters based on the verification code generation rules.

[0110] S104: Return the verification code generation parameters to the client so that the client can generate the corresponding verification code according to the verification code generation parameters.

[0111] In this embodiment, when a user logs into a client and opens the client's front-end page, since a verification mechanism is introduced in the application corresponding to the client in this application, the verification mechanism allows the user to perform related operations such as login, registration, or password retrieval on the front-end page. The client can send a verification code retrieval request to the server based on the verification code retrieval operation triggered by the user. The server can generate corresponding verification code generation parameters based on the verification code retrieval request sent by the client and return the verification code generation parameters to the client. The client can then generate the corresponding verification code based on the verification code generation parameters.

[0112] Specifically, when the server receives the verification code retrieval request and the corresponding third-party tracking information sent by the client, it can match the third-party tracking information with the preset verification code generation rules. If the match is successful, it indicates that the current client needs to use a verification code for verification. At this time, the server can determine the corresponding verification code generation parameters according to the verification code generation rules and return the verification code generation parameters to the client. The client saves all the front-end styles of the verification codes. When the client receives the verification code generation parameters, it can determine the corresponding front-end style according to the verification code generation parameters, thereby generating the corresponding verification code and uploading the verification code input result to the server.

[0113] It is understood that the third tracking information in this application includes tracking information related to user information, user behavior, device status, etc. when the user enters the verification code; while the verification code generation rule in this application refers to the generation conditions and generation strategy when generating the verification code. The generation conditions can be used to determine whether the user logging into the client is a blacklisted user, whether the frequency of the user accessing the interface is high, whether the device logging into the client is normal, and whether the user's behavior trajectory on the client's front-end page is normal, etc.; the generation strategy can include whether a verification code is needed, and what type of verification code is needed, etc.

[0114] The verification code generation parameters in this application refer to the verification code-related parameter information generated according to the generation strategy in the verification code generation rules, which enables the client 120 to generate a verification code, such as verification code type, verification code ID, etc.

[0115] Therefore, after the server obtains the third-level tracking information, it can match the third-level tracking information with the generation conditions in the preset verification code generation rules to determine whether the input parameter data meets the generation conditions in the preset verification code generation rules. If it does, the server can determine the corresponding verification code generation parameters based on the generation strategy in the verification code generation rules and send the verification code generation parameters to the corresponding client so that the client can generate the corresponding verification code.

[0116] The verification code verification method of this application will be illustrated below through a series of examples. In one specific implementation, such as... Figure 2 As shown, Figure 2 This is a schematic diagram of the verification code verification process provided in an embodiment of the present invention; Figure 2 In the process, when a user triggers the verification code acquisition process in certain key scenarios (such as login and registration), the captcha backend domain can determine whether a verification code is needed based on the current user's device status, user behavior, etc. Once it is confirmed that a verification code is needed, the corresponding verification code generation parameters are sent to the frontend so that the frontend component generates the corresponding verification code and allows the user to enter the verification code as required.

[0117] When a user enters a verification code, the front-end component can convert the input verification code content into a checksum based on different verification code types (plain image / Chinese / selection / question, etc.) and different logic. This checksum is then merged into the current request data (e.g., a timestamp) and sent to the risk control FDS via the captcha interface. The risk control FDS service parses the checksum data, calculates the checksum verification result, and stores the mapping between the checksum verification result and the current UID / phone number. If the verification code passes verification in the current scenario, and the user continues to the order placement process (e.g., adding to cart or submitting the order), they need to request the risk control FDS service again. At this point, the underlying risk control system can determine whether the checksum information is abnormal based on the user's input UID or phone number. If abnormal, a second verification will be performed or the system will directly block the request.

[0118] Here, CAPTCHA refers to a verification code used for human-machine identification, and FDS stands for Fraud Detection System, used for risk assessment; while Figure 2 In this context, osp-captcha.api.vip.com refers to the Captcha backend domain, which is mainly used for OSP servers, provides OSP interfaces, and is accessible from the intranet.

[0119] The verification code verification device provided in the embodiments of this application is described below. The verification code verification device described below can be referred to in correspondence with the verification code verification method described above.

[0120] In one embodiment, such as Figure 3 As shown, Figure 3 This is a schematic diagram of a verification code verification device provided in an embodiment of the present invention. The present invention also provides a verification code verification device, which may include a data receiving module 210, a verification bit verification module 220, and a verification code verification module 230, specifically including the following:

[0121] The data receiving module 210 is used to obtain the verification code input result sent by the client and the first embedded point information.

[0122] The verification bit verification module 220 is used to verify whether the first embedded information contains a first verification bit corresponding to the verification code input result, and whether the first verification bit is abnormal, and to obtain a verification result.

[0123] The verification code verification module 230 is used to verify the verification code input result based on the verification result.

[0124] In the above embodiments, after the server obtains the verification code input result and the first tracking information sent by the client, it can verify whether the first tracking information contains a first check bit corresponding to the verification code input result, and whether the first check bit is abnormal, and obtain the verification result. Then, the verification code input result can be verified according to the verification result. In this application, the server can verify whether the first tracking information contains a first check bit corresponding to the verification code input result, and whether the first check bit is abnormal, so as to determine whether the current verification operation is an abnormal operation. For example, if the first tracking information does not contain a first check bit, or the first check bit is abnormal, it can be determined that the current verification operation is an abnormal operation. Then, the user can be intercepted directly, or the user can be intercepted when requesting to enter a specific stage, thereby effectively preventing malicious attacks by hackers. In addition, the first check bit in this application is hidden in the first tracking information, making it difficult for hackers to discover the existence of the check bit function when carrying out malicious attacks, thereby confusing hackers to a certain extent and further improving the risk resistance of the verification mechanism.

[0125] In one embodiment, the verification code verification module 230 may include:

[0126] The first result acquisition module is used if the first tracking information does not contain a first verification bit corresponding to the verification code input result; or if the first tracking information contains a first verification bit corresponding to the verification code input result, and the first verification bit is abnormal.

[0127] The first interception module is used to intercept the verification operation of the user logging into the client without verifying the verification code input result.

[0128] In one embodiment, the verification code verification module 230 may include:

[0129] The second result acquisition module is used to determine if the first tracking information does not contain a first verification bit corresponding to the verification code input result; or if the first tracking information contains a first verification bit corresponding to the verification code input result, and the first verification bit is abnormal.

[0130] The verification code verification submodule is used to verify the verification code input result using a preset verification code answer, and return a verification successful instruction to the client when the verification code input result is correct.

[0131] The information acquisition module is used to acquire the request instruction triggered by the user on the client after verification to enter a specific stage, as well as the second embedded point information corresponding to the request instruction.

[0132] The second interception module is used to intercept the user's operation of entering the specific stage when the user information in the second tracking information corresponds to the user information in the first tracking information.

[0133] In one embodiment, the check bit verification module 220 may include:

[0134] The data parsing module is used to parse the parameters contained in the first embedded information and determine whether the first embedded information contains a first verification bit corresponding to the verification code input result.

[0135] The verification bit conversion module is used to convert the verification code input result into a second verification bit according to the conversion method agreed with the client if the verification bit is included, and to verify whether the first verification bit is abnormal based on the second verification bit.

[0136] In one embodiment, the check bit conversion module may include:

[0137] The merging module is used to convert the verification code input result into the corresponding number and then merge them according to the verification code type corresponding to the verification code input result.

[0138] The calculation module is used to calculate the merged numbers according to a preset calculation method to obtain a number of preset length, and use the number of preset length as the second check digit.

[0139] In one embodiment, the check bit conversion module may include:

[0140] The comparison module is used to compare the second check bit with the first check bit.

[0141] The anomaly confirmation module is used to verify whether the first check bit is abnormal based on the comparison result.

[0142] In one embodiment, the apparatus may further include:

[0143] The request and response module is used to receive the verification code retrieval request sent by the client and the corresponding third-party tracking information.

[0144] The judgment module is used to determine whether the third embedded information meets the preset verification code generation rules.

[0145] The parameter generation module is used to determine the corresponding verification code generation parameters based on the verification code generation rules if the conditions are met.

[0146] The verification code generation module is used to return the verification code generation parameters to the client, so that the client can generate the corresponding verification code according to the verification code generation parameters.

[0147] In one embodiment, the present invention also provides a storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the CAPTCHA verification method as described in any of the above embodiments.

[0148] In one embodiment, the present invention also provides a computer device comprising: one or more processors, and a memory.

[0149] The memory stores computer-readable instructions, which, when executed by the one or more processors, perform the steps of the verification code verification method as described in any of the above embodiments.

[0150] Indicatively, such as Figure 4 As shown, Figure 4 This is a schematic diagram of the internal structure of a computer device 300 provided in an embodiment of the present invention. The computer device 300 can be provided as a server. (Refer to...) Figure 4The computer device 300 includes a processing component 302, which further includes one or more processors, and memory resources represented by memory 301 for storing instructions, such as application programs, that can be executed by the processing component 302. The application programs stored in memory 301 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 302 is configured to execute instructions to perform the CAPTCHA verification method of any of the above embodiments.

[0151] The computer device 300 may also include a power supply component 303 configured to perform power management of the computer device 300, a wired or wireless network interface 304 configured to connect the computer device 300 to a network, and an input / output (I / O) interface 305. The computer device 300 may operate on an operating system stored in memory 301, such as Windows Server™, Mac OS X™, Unix™, Linux™, Free BSD™, or similar.

[0152] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0153] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0154] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.

[0155] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A verification code verification method, characterized in that, The method includes: Obtain the verification code input result sent by the client and the first tracking point information; The verification result is obtained by verifying whether the first embedded information contains a first verification bit corresponding to the verification code input result and whether the first verification bit is abnormal. The verification code input result is validated based on the verification result. The verification of whether the first embedded information contains a first verification bit corresponding to the verification code input result, and whether the first verification bit is abnormal, includes: The parameters contained in the first embedded information are parsed, and the parsing results are used to determine whether the first embedded information contains a first verification bit corresponding to the verification code input result. If included, the verification code input result is converted according to the conversion method agreed upon with the client to obtain the second verification bit, and the first verification bit is verified to be abnormal based on the second verification bit.

2. The verification code verification method according to claim 1, characterized in that, The verification code input result is validated based on the verification result, including: If the first embedded information does not contain the first verification bit corresponding to the verification code input result. Alternatively, the first embedded information may contain a first verification bit corresponding to the verification code input result, and the first verification bit may be abnormal. Therefore, there is no need to verify the input result of the verification code or intercept the verification operation of the user logging into the client.

3. The verification code verification method according to claim 1, characterized in that, The verification code input result is validated based on the verification result, including: If the first embedded information does not contain the first verification bit corresponding to the verification code input result. Alternatively, the first embedded information may contain a first verification bit corresponding to the verification code input result, and the first verification bit may be abnormal. The system then uses a preset verification code answer to verify the verification code input result, and returns a verification successful instruction to the client when the verification code input result is correct; After successful verification, obtain the request instruction triggered by the user on the client to enter a specific stage, and the second embedded point information corresponding to the request instruction; When the user information in the second tracking information corresponds to the user information in the first tracking information, the user's operation to enter the specific stage is intercepted.

4. The verification code verification method according to claim 1, characterized in that, The step of converting the verification code input result according to the conversion method agreed upon with the client to obtain the second verification bit includes: Based on the verification code type corresponding to the verification code input result, the verification code input result is converted into the corresponding number and then merged; The merged numbers are calculated according to a preset calculation method to obtain a number of preset length, and the number of preset length is used as the second check digit.

5. The verification code verification method according to claim 1, characterized in that, The step of verifying whether the first check bit is abnormal based on the second check bit includes: Compare the second check bit with the first check bit; Verify whether the first check bit is abnormal based on the comparison results.

6. The verification code verification method according to claim 1, characterized in that, Before obtaining the verification code input result sent by the client and the first tracking information, the process also includes: Receive the verification code retrieval request sent by the client and the corresponding third-party tracking information; Determine whether the third embedded information meets the preset verification code generation rules; If the conditions are met, the corresponding verification code generation parameters are determined based on the verification code generation rules. The verification code generation parameters are returned to the client so that the client can generate the corresponding verification code based on the verification code generation parameters.

7. A verification code verification device, characterized in that, include: The data receiving module is used to obtain the verification code input result sent by the client and the first embedded point information; The verification bit verification module is used to verify whether the first embedded information contains a first verification bit corresponding to the verification code input result, and whether the first verification bit is abnormal, and to obtain the verification result. The verification code verification module is used to verify the verification code input result based on the verification result; The verification bit verification module includes: The parameters contained in the first embedded information are parsed, and the parsing results are used to determine whether the first embedded information contains a first verification bit corresponding to the verification code input result. If included, the verification code input result is converted according to the conversion method agreed upon with the client to obtain the second verification bit, and the first verification bit is verified to be abnormal based on the second verification bit.

8. A storage medium, characterized in that: The storage medium stores computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the verification code verification method as described in any one of claims 1 to 6.

9. A computer device, characterized in that, include: One or more processors, and memory; The memory stores computer-readable instructions, which, when executed by the one or more processors, perform the steps of the verification code verification method as described in any one of claims 1 to 6.

Images