Token leakage verification method, device and storage medium

Abstract

The present invention discloses a token leakage verification method, device and storage medium. Since data will not be received until it is sent out when a client communicates with a server, the number of times the server receives communication data must be less than or equal to the number of times the client sends communication data. The present application records the number of times communication data is received from the client and compares it with the number of times the client sends communication data. When the number of times received is greater than the number of times sent, there must be an additional sending device. Since the token is only issued to the client, it is determined that there is a token leakage, and the token leakage verification is implemented. This solves the problem in the prior art that when tokens are used to verify user information, data security is affected by token leakage, and the effect of ensuring data security is achieved.

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of data security technology, and in particular to a token leakage verification method, device and storage medium. Background Art

[0002] Http protocol (Hypertext Transfer Protocol) is an application layer protocol for distributed, collaborative and hypermedia information systems; it is the basis of data communication on the World Wide Web. When we open a browser to browse the web or use mobile software, a large amount of data is transmitted between the client and the server through the Http protocol.

[0003] Token is a token. Since the HTTP protocol is stateless, the server cannot know which user initiated a request. The token is a proof that shows who initiated a HTTP request. Usually, after a successful login, the client program will receive a token returned by the server program, which contains the unique identity of the logged-in user, the validity period and other information and is encrypted by the server. All subsequent HTTP requests sent by the client to the backend must carry the token. After receiving the request, the server will decrypt the token and determine the validity of the request based on the decryption result.

[0004] Since the http protocol itself is not encrypted, a third-party client only needs to intercept the string representing the token to forge the user's identity. At this time, the user's data security cannot be guaranteed. Therefore, the server usually records the user's operations after logging in and records them in the log. When the user checks the log and finds abnormal operations, the token leakage can be discovered. However, most users lack the habit of querying logs, and usually the interval between the discovery of the leakage and the leakage is long. At this time, the data has been leaked, and the log may be tampered with, so data security is still not guaranteed. Summary of the invention

[0005] The embodiment of the present invention provides a token leakage verification method, which verifies the leakage of the token at a preset time interval and promptly discovers the leakage of the token. This solves the technical problem in the prior art that the interval between the discovery of the leakage and the actual leakage is long, and the data has already been leaked at this time, thereby achieving the technical effect of ensuring data security.

[0006] The present invention provides a token leakage verification method, comprising:

[0007] In response to the login request initiated by the target client, verify the login information of the target client, and send the public key and token to the target client when the verification passes;

[0008] In response to the communication data and verification information containing the token returned by the target client, decrypt the verification information of the target client using the private key, and record the number of receptions of the communication with the target client based on the communication data containing the token and the decrypted verification information;

[0009] The number of times the target client sends communication data is obtained based on the decrypted verification information. When the number of receptions is greater than the number of initiations, it is determined that the token of the target client has been leaked.

[0010] Preferably, it also includes:

[0011] Reject all requests from the target client and send the login page to the target client;

[0012] Verify the login information returned by the target client. When the verification passes, send the new public key and new token to the target client.

[0013] Preferably, in response to a login request initiated by a target client, verifying the login information of the target client, and sending a public key and a token to the target client when the verification passes specifically includes:

[0014] In response to a login request initiated by a target client, the login information sent by the target client is obtained, and a key pair is generated according to an RSA algorithm;

[0015] Obtain the user name, password and device number of the target client sent by the target client according to the login information;

[0016] Compare the username and password sent by the target client with the username and password stored in the database. When the username and password are correct, generate a token based on the client's device number.

[0017] Send the generated token and public key to the target client.

[0018] Preferably, in response to the communication data and verification information containing the token returned by the target client, decrypting the verification information of the target client using the private key, and recording the number of reception times of communication with the target client according to the communication data containing the token and the decrypted verification information specifically includes:

[0019] Receive the communication data and verification information including token returned by the target client;

[0020] Use the private key to decrypt the verification information of the target client, and obtain the start recording command and the end recording command according to the decrypted verification information;

[0021] Records the number of times the target client receives communications between the start recording command and the end recording command.

[0022] Preferably, the number of initiation times of the target client sending communication data is obtained according to the decrypted verification information. When the number of reception times is greater than the number of initiation times, the step of determining that the token of the target client has been leaked specifically includes:

[0023] Obtaining the number of times the target client initiates communication with the target client between the start recording command and the end recording command according to the decrypted verification information;

[0024] When the number of receptions is greater than the number of initiations, it is determined that the target client's token has been leaked.

[0025] Preferably, it includes:

[0026] Send a login request to the target server, and receive the public key and token sent by the target server when the login is successful;

[0027] Use the public key to encrypt the verification information containing the start recording command, and use the token to send the encrypted verification information and communication data;

[0028] After the preset time, the verification information including the stop recording command and the number of initiations is encrypted using the public key, and the encrypted verification information and communication data are sent using the token; the number of initiations is the number of communications initiated to the client from the start recording command to the stop recording command;

[0029] When receiving the login page sent by the server, it is determined that the token has been leaked.

[0030] Preferably, it also includes:

[0031] When the login page or verification pass signal is not received within the preset interval, the verification information including the stop recording command and the number of initiations is encrypted to the server using the public key, and the encrypted verification information and communication data are sent using the token;

[0032] If the login page or verification pass signal is not received again within the preset interval, the token and public key are deleted and a login request is sent to the server.

[0033] Preferably, it also includes:

[0034] Use the public key to encrypt verification information including non-recorded commands, and use the token to send the encrypted verification information and communication data;

[0035] Use the public key to encrypt the verification information containing the random string, and use the token to send the encrypted verification information and communication data.

[0036] The present invention also proposes a token leakage verification device, which includes: a memory, a processor, and a token leakage verification program stored in the memory and executable on the processor, wherein the token leakage verification program implements the above token leakage verification method when executed by the processor.

[0037] The present invention also proposes a readable storage medium, on which a token leakage verification program is stored. When the token leakage verification program is executed by a processor, the steps of the above token leakage verification method are implemented.

[0038] The present invention records the number of times communication data is received from the client and compares it with the number of times communication data is sent by the client. When the number of times ... BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 It is a flowchart of an embodiment of the task automatic configuration method of the present invention;

[0040] Figure 2 is a flow chart of another embodiment of the task automatic configuration method of the present invention;

[0041] Figure 3 is a flow chart of another embodiment of the task automatic configuration method of the present invention;

[0042] Figure 4 It is a schematic diagram of the device structure in an embodiment of the present invention. DETAILED DESCRIPTION

[0043] The present invention will be further described in detail below in conjunction with the accompanying drawings and embodiments. It is to be understood that the specific embodiments described herein are only used to explain the present invention, rather than to limit the present invention. It should also be noted that, for ease of description, only parts related to the present invention, rather than all structures, are shown in the accompanying drawings.

[0044] Figure 1 A flowchart of a token leakage verification method provided by an embodiment of the present invention specifically includes:

[0045] S100, in response to a login request initiated by a target client, verify the login information of the target client, and send a public key and a token to the target client when the verification passes;

[0046] It should be noted that the login process also includes the server sending a login page, the client filling in the account number and password on the login page, and the server verifying the account number and password after receiving them. This process is consistent with the existing technical solutions, and other existing login methods can also be used. The specific login steps and account number and password security protection methods exist for a large number of prior arts, which can be applied to the technical solution of this application without the need for additional creative work, and will not be described one by one here.

[0047] S200, in response to the communication data and verification information containing the token returned by the target client, decrypt the verification information of the target client using the private key, and record the number of receptions of the communication with the target client according to the communication data containing the token and the decrypted verification information;

[0048] It is worth emphasizing that this application verifies whether the token is leaked through verification information. Since the commands to start recording and stop recording are located in the verification information, in order to obtain the number of receptions of communications with the target client, it is necessary to first decrypt the verification information and start recording and stop recording according to the commands in the verification information before the number of receptions of communications with the target client can be obtained.

[0049] S300, obtaining the number of times the target client sends communication data according to the decrypted verification information, and when the number of times received is greater than the number of times initiated, determining that the token of the target client has been leaked.

[0050] It should be emphasized that due to network failures, packet loss may occur. Under normal circumstances, some communication data may be sent but not received by the server, but there will be no situation where the server receives the data repeatedly. Therefore, if the token is not leaked, the number of times the server receives the data must be less than the number of times the client sends the data. If the data is not sent, the server cannot receive the data. Therefore, if the number of times the server receives the data is greater than the number of times the client sends the data, it is judged that a third party uses the token to send communication data to the server, that is, the token has been leaked.

[0051] The technical solution of this embodiment records the number of times communication data is received from the client and compares it with the number of times the communication data is sent by the client. When the number of times ... which are of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same number of numbers of the same

[0052] Reference Figure 2 , Figure 22 is a flow chart of another embodiment of the task automatic configuration method of the present invention. The token leakage verification method provided by the present invention includes the following steps in addition to the above steps S100-S300:

[0053] S400, rejecting all requests from the target client and sending a login page to the target client;

[0054] It is easy to understand that when the token is leaked, in order to avoid user data leakage, the server will reject all requests sent by the client or the third party. Since the server determines the target client based on the token, the third party is also the target client in the eyes of the server. Therefore, the execution logic here is to reject all requests from the target client, which is actually to reject all requests from the target client and the third party.

[0055] It should be noted that at this time, the target client still has communication needs, but the account and password have not been leaked, so a login page can be sent to the target client to verify the identity information of the target client through the account and password.

[0056] S500: Verify the login information returned by the target client. If the verification is successful, send a new public key and a new token to the target client.

[0057] It should be noted that since the token has been leaked, after verifying the identity information of the target client, a new token is issued to continue communicating with the target client. At this time, since the third-party token is an old token, it can be recognized by the server to reject the third-party communication and ensure data security.

[0058] Reference Figure 3 , Figure 3 It is a flowchart of another embodiment of the task automatic configuration method of the present invention.

[0059] In response to a login request initiated by a target client, verifying the login information of the target client, and sending a public key and a token to the target client when the verification passes, the steps specifically include:

[0060] S110, in response to a login request initiated by a target client, obtaining login information sent by the target client, and generating a key pair according to an RSA algorithm;

[0061] It should be noted that the RSA algorithm is an asymmetric encryption algorithm, which usually generates a pair of RSA keys, one of which is a private key, i.e., a confidential key, which is stored by the server; the other is a public key, which can be made public and is sent to the target client in this embodiment; when encrypting and transmitting content, for example, the client wants to transmit information to the server, the client first encrypts the content with the public key given by the server and then transmits it, and the server decrypts the information transmitted by the client with its own private key after receiving it. In this process, as long as the server does not disclose its own private key, even if a third party intercepts the information, it cannot decrypt and obtain the content information without the private key of the server. Even if this encryption method uses an unencrypted transmission protocol such as http, since the data transmitted in the http protocol is encrypted, even if it is intercepted, it is necessary to perform a complete decryption step to obtain the real transmission information.

[0062] S120, obtaining the user name, password and device number of the target client sent by the target client according to the login information;

[0063] It is worth emphasizing that the token is usually generated based on the client's device number, and after obtaining the device number, it can be analyzed whether it is a commonly used device. This is helpful for adjusting the interval between the start and end recording commands, and can reduce the detection frequency to a certain extent, thereby reducing the computing and storage pressure on the server.

[0064] S130, comparing the username and password sent by the target client with the username and password stored in the database, and when the username and password are correct, generating a token according to the device number of the client;

[0065] It is worth noting that the above steps include the conventional steps of verifying whether the username and password are correct, and the steps of generating a token. In the prior art, there is also a method of sending the username and password to a database, and the database compares the username and password to verify the username and password. This embodiment verifies the username and password first and then generates a token. This avoids the problem that the token generated after the username and password verification fails is invalid and can only be deleted, causing a waste of computing resources, thereby reducing the computing pressure on the server.

[0066] S140. Send the generated token and public key to the target client.

[0067] It is easy to understand that the public key can also be used to encrypt communication data. When the amount of data is large, the computing performance requirements will increase accordingly. Therefore, the instruction data in the communication data and other data that does not need to be kept confidential and does not involve privacy leakage can be sent to the server without encryption.

[0068] Specifically, in response to the communication data and verification information containing the token returned by the target client, the verification information of the target client is decrypted using the private key, and according to the communication data containing the token and the decrypted verification information, the step of recording the number of receptions of the communication with the target client specifically includes:

[0069] Receive the communication data and verification information including token returned by the target client;

[0070] It should be noted that the server identifies the data sent by different clients based on the received token in order to communicate with multiple clients at the same time. Therefore, the data returned by the client needs to include the token, and the communication data and verification data can be packaged into one data for transmission, in which the verification data must be encrypted, while the communication data can be unencrypted.

[0071] Use the private key to decrypt the verification information of the target client, and obtain the start recording command and the end recording command according to the decrypted verification information;

[0072] It is worth emphasizing that when the client uses the token to communicate for a period of time and the token is at risk of being leaked, the client will send a start recording command to the server; the server will start recording according to the start recording command until it receives a stop recording command.

[0073] Records the number of times the target client receives communications between the start recording command and the end recording command.

[0074] It is easy to understand that the stop recording command and the number of initiations are sent to the server through the same verification information. Therefore, after receiving the stop recording command, it is possible to obtain whether the token has been leaked without the need for additional communication.

[0075] Specifically, the number of times the target client sends communication data is obtained according to the decrypted verification information. When the number of receptions is greater than the number of initiations, the steps of determining that the token of the target client has been leaked specifically include:

[0076] Obtaining the number of times the target client initiates communication with the target client between the start recording command and the end recording command according to the decrypted verification information;

[0077] It is worth emphasizing that the number of initiations is counted by the client and sent to the server through verification information. The number of initiations also counts the number of times there is communication data when the client sends a start recording command and sends an end recording command.

[0078] When the number of receptions is greater than the number of initiations, it is determined that the target client's token has been leaked.

[0079] It should be noted that since there is no situation where information is received before being sent, and taking into account the packet loss during data transmission, the number of initiations should always be greater than the number of receptions. Even if there is no packet loss, the number of initiations should be equal to the number of receptions. Only when a third party uses the target client's token to communicate with the server will the number of receptions be greater than the number of initiations.

[0080] This embodiment improves the technical solution by disclosing the processing method after the token is leaked. At the same time, the method of using the RSA algorithm to generate a key pair further improves the security of the data and further refines the security during data transmission, thereby minimizing the possibility of modification of the verification information of this application and improving the user experience.

[0081] This embodiment also proposes a token leakage verification method, including:

[0082] Send a login request to the target server, and receive the public key and token sent by the target server when the login is successful;

[0083] It is easy to understand that the client needs to obtain a token before it can access the server with the identity stored in the database without having to enter the account and password every time, and the public key can be used to encrypt verification information to ensure the security of verification information transmitted in the http protocol.

[0084] Use the public key to encrypt the verification information containing the start recording command, and use the token to send the encrypted verification information and communication data;

[0085] It should be noted that the public key can also encrypt communication data. However, the communication data contains private data and instruction data, and instruction data does not need to be encrypted for transmission. The existing encryption algorithms can also protect the transmission security of private data to a certain extent. Therefore, communication data does not need to be encrypted using the public key. Of course, in order to ensure privacy security, private data can also be encrypted using the public key before being sent to the server.

[0086] After the preset time, the verification information including the stop recording command and the number of initiations is encrypted using the public key, and the encrypted verification information and communication data are sent using the token; the number of initiations is the number of communications initiated to the client from the start recording command to the stop recording command;

[0087] It is worth emphasizing that communication data is not always available. The stop recording command or start recording command can be sent directly to the server without the communication data. However, the statistics of the number of initiations and receptions only count the number of times that include communication data to reduce the total amount of data and the amount of calculation.

[0088] When receiving the login page sent by the server, it is determined that the token has been leaked.

[0089] It is worth noting that when the number of receptions is greater than the number of initiations, the server will determine that the token has been leaked. At this time, it will send a login page to guide the user to log in again to confirm the user's identity. Therefore, when the client receives the login page, it can be known that the token has been leaked.

[0090] Specifically, it also includes:

[0091] When the login page or verification pass signal is not received within the preset interval, the verification information including the stop recording command and the number of initiations is encrypted to the server using the public key, and the encrypted verification information and communication data are sent using the token;

[0092] It is easy to understand that the login page sent by the server may not be received by the client due to network instability such as packet loss, or the verification information and communication data sent to the server may be lost. Therefore, the client can resend the verification information and communication data to the server after a preset interval.

[0093] If the login page or verification pass signal is not received again within the preset interval, the token and public key are deleted and a login request is sent to the server.

[0094] It should be noted that when the preset interval time is exceeded again, the server may think that the token has been lost and therefore will not respond to the client command. Therefore, the login request is sent again without using the token and public key. Since the server distinguishes different clients through tokens, it can respond to login requests without tokens.

[0095] Specifically, it also includes:

[0096] Use the public key to encrypt verification information including non-recorded commands, and use the token to send the encrypted verification information and communication data;

[0097] It is worth emphasizing that since the proofreading information is sent to the server at preset intervals, the main purpose of not recording the command is to maintain the connection with the server and avoid the server deleting the client's token after a long period of disconnection, resulting in unnecessary repeated logins.

[0098] Use the public key to encrypt the verification information containing the random string, and use the token to send the encrypted verification information and communication data.

[0099] It should be noted that usually the verification information uses simple characters such as 0 and 1 to represent the start and end recording commands. Even after encryption, such simple characters are easy to find patterns. Therefore, by adding random strings, the encryption results are obfuscated to further ensure data security during transmission.

[0100] This embodiment improves the technical solution by disclosing the execution method of the client, reduces the computational workload of the server to a certain extent, and improves the computational efficiency of the server. At the same time, by introducing non-recording commands, unnecessary repeated logins are avoided, thereby improving the user experience. At the same time, the encryption result of the verification information is obfuscated with a random string, further ensuring the security of the data transmission process, thereby ensuring the security of user privacy data and further ensuring data security.

[0101] like Figure 4 As shown, Figure 4 7 is a schematic diagram of the device structure of another embodiment of the present invention. The device includes a processor 70, a memory 71, an input device 72 and an output device 73; the number of processors 70 in the server can be one or more. Figure 4 A processor 70 is taken as an example; the processor 70, the memory 71, the input device 72 and the output device 73 in the server can be connected by a bus or other means. Figure 4 The example of connecting through bus is taken in the following.

[0102] The memory 71 is a computer-readable storage medium that can be used to store software programs, computer executable programs and modules, such as program instructions corresponding to the token leakage verification method in the embodiment of the present invention. The processor 70 executes various functional applications and data processing of the server by running the software programs, instructions and modules stored in the memory 71, that is, implementing the above-mentioned token leakage verification method.

[0103] The memory 71 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system and at least one application required for a function; the data storage area may store data created according to the use of the terminal, etc. In addition, the memory 71 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 71 may further include a memory remotely arranged relative to the processor 70, and these remote memories may be connected to the server via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0104] The input device 72 may be used to receive input digital or character information and generate key signal input related to the user settings and function control of the server. The output device 73 may include a display server such as a display screen.

[0105] This embodiment has functional modules and beneficial effects corresponding to the execution method, which will not be described in detail here.

[0106] An embodiment of the present invention further provides a storage medium including computer executable instructions, which are used to execute a token leakage verification method when executed by a computer processor. The method includes:

[0107] In response to the login request initiated by the target client, verify the login information of the target client, and send the public key and token to the target client when the verification passes;

[0108] In response to the communication data and verification information containing the token returned by the target client, decrypt the verification information of the target client using the private key, and record the number of receptions of the communication with the target client based on the communication data containing the token and the decrypted verification information;

[0109] The number of times the target client sends communication data is obtained based on the decrypted verification information. When the number of receptions is greater than the number of initiations, it is determined that the token of the target client has been leaked.

[0110] Specifically, it also includes:

[0111] Reject all requests from the target client and send the login page to the target client;

[0112] Verify the login information returned by the target client. When the verification passes, send the new public key and new token to the target client.

[0113] Specifically, in response to a login request initiated by a target client, verifying the login information of the target client, and sending a public key and a token to the target client when the verification passes, the steps specifically include:

[0114] In response to a login request initiated by a target client, the login information sent by the target client is obtained, and a key pair is generated according to an RSA algorithm;

[0115] Obtain the user name, password and device number of the target client sent by the target client according to the login information;

[0116] Compare the username and password sent by the target client with the username and password stored in the database. When the username and password are correct, generate a token based on the client's device number.

[0117] Send the generated token and public key to the target client.

[0118] Specifically, in response to the communication data and verification information containing the token returned by the target client, the verification information of the target client is decrypted using the private key, and according to the communication data containing the token and the decrypted verification information, the step of recording the number of receptions of the communication with the target client specifically includes:

[0119] Receive the communication data and verification information including token returned by the target client;

[0120] Use the private key to decrypt the verification information of the target client, and obtain the start recording command and the end recording command according to the decrypted verification information;

[0121] Records the number of times the target client receives communications between the start recording command and the end recording command.

[0122] Specifically, the number of times the target client sends communication data is obtained according to the decrypted verification information. When the number of times received is greater than the number of times initiated, the steps of determining that the token of the target client has been leaked specifically include:

[0123] Obtain the number of times the target client initiates communication with the target client between the start recording command and the end recording command according to the decrypted verification information;

[0124] When the number of receptions is greater than the number of initiations, it is determined that the target client's token has been leaked.

[0125] Specifically, it includes:

[0126] Send a login request to the target server, and receive the public key and token sent by the target server when the login is successful;

[0127] Use the public key to encrypt the verification information containing the start recording command, and use the token to send the encrypted verification information and communication data;

[0128] After the preset time, the verification information including the stop recording command and the number of initiations is encrypted using the public key, and the encrypted verification information and communication data are sent using the token; the number of initiations is the number of communications initiated to the client from the start recording command to the stop recording command;

[0129] When receiving the login page sent by the server, it is determined that the token has been leaked.

[0130] Specifically, it also includes:

[0131] When the login page or verification pass signal is not received within the preset interval, the verification information including the stop recording command and the number of initiations is encrypted to the server using the public key, and the encrypted verification information and communication data are sent using the token;

[0132] If the login page or verification pass signal is not received again within the preset interval, the token and public key are deleted and a login request is sent to the server.

[0133] Specifically, it also includes:

[0134] Use the public key to encrypt verification information including non-recorded commands, and use the token to send the encrypted verification information and communication data;

[0135] Use the public key to encrypt the verification information containing the random string, and use the token to send the encrypted verification information and communication data.

[0136] Of course, the storage medium containing computer executable instructions provided in an embodiment of the present invention is not limited to the above method operations, but can also execute related operations in the token leakage verification method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method, which will not be described one by one here.

[0137] Through the above description of the implementation mode, the technicians in the relevant field can clearly understand that the present invention can be implemented by means of software and necessary general hardware, and of course can also be implemented by hardware, but in many cases the former is a better implementation mode. Based on such an understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as a computer floppy disk, a read-only memory (ROM), a random access memory (RAM), a flash memory (FLASH), a hard disk or an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods of various embodiments of the present invention.

[0138] It is worth noting that in the embodiment of the above-mentioned search device, the various units and modules included are only divided according to functional logic, but are not limited to the above-mentioned division, as long as the corresponding functions can be achieved; in addition, the specific names of the functional units are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of the present invention.

[0139] Note that the above are only preferred embodiments of the present invention and the technical principles used. Those skilled in the art will understand that the present invention is not limited to the specific embodiments herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in more detail through the above embodiments, the present invention is not limited to the above embodiments, and may include more other equivalent embodiments without departing from the concept of the present invention, and the scope of the present invention is determined by the scope of the appended claims.

Claims

1. A token leakage verification method, characterized in that: include: In response to a login request initiated by a target client, verify the login information of the target client, and send a public key and a token to the target client when the verification passes; In response to the communication data and verification information containing the token returned by the target client, decrypt the verification information of the target client using the private key, and record the number of receptions of the communication with the target client according to the communication data containing the token and the decrypted verification information; Obtaining the number of initiation times of the target client sending communication data according to the decrypted verification information, and when the number of receptions is greater than the number of initiation times, judging that the token of the target client has been leaked, rejecting all requests of the target client, and sending a login page to the target client; In response to the communication data and verification information containing the token returned by the target client, the step of decrypting the verification information of the target client using a private key, and recording the number of reception times of communication with the target client according to the communication data containing the token and the decrypted verification information specifically includes: Receive the communication data and verification information including the token returned by the target client; Decrypt the verification information of the target client using a private key, and obtain a start recording command and an end recording command according to the decrypted verification information; Recording the number of times the target client is communicated with between the start recording command and the end recording command; The step of responding to the login request initiated by the target client, verifying the login information of the target client, and sending the public key and token to the target client when the verification passes specifically includes: In response to a login request initiated by a target client, obtaining login information sent by the target client, and generating a key pair according to an RSA algorithm; Acquire the user name, password and device number of the target client sent by the target client according to the login information; Compare the username and password sent by the target client with the username and password stored in the database, and when the username and password are correct, generate a token according to the device number of the client; Send the generated token and public key to the target client.

2. The token leakage verification method according to claim 1, characterized in that: Also includes: Reject all requests from the target client and send a login page to the target client; Verify the login information returned by the target client, and when the verification passes, send a new public key and a new token to the target client.

3. The token leakage verification method according to claim 1, characterized in that: The step of obtaining the number of initiation times of the target client sending communication data according to the decrypted verification information, and when the number of reception times is greater than the number of initiation times, determining that the token of the target client has been leaked specifically includes: Obtaining the number of times the target client initiates communication with the target client between the start recording command and the end recording command according to the decrypted verification information; When the number of receptions is greater than the number of initiations, it is determined that the token of the target client has been leaked.

4. A token leakage verification method, characterized in that: include: Send a login request to the target server, and when the login is successful, receive the public key and token sent by the target server; Use the public key to encrypt the verification information containing the start recording command, and use the token to send the encrypted verification information and communication data; After a preset time, the verification information including the stop recording command and the number of initiations is encrypted using the public key, and the encrypted verification information and communication data are sent using the token; the number of initiations is the number of communications initiated to the client from the start recording command to the stop recording command; Upon receiving the login page sent by the server, it is determined that the token has been leaked; The method further comprises: When the login page or verification pass signal is not received within the preset interval, the verification information including the stop recording command and the number of initiations is encrypted to the server using the public key, and the encrypted verification information and communication data are sent using the token; When the login page or verification pass signal is not received again within the preset interval, the token and public key are deleted, and a login request is sent to the server; The method further comprises: Use the public key to encrypt verification information including non-recorded commands, and use the token to send the encrypted verification information and communication data; Use the public key to encrypt the verification information containing the random string, and use the token to send the encrypted verification information and communication data.

5. A token leakage verification device, characterized in that: The token leakage verification device includes: a memory, a processor, and a token leakage verification program stored in the memory and executable on the processor, wherein the token leakage verification program implements the token leakage verification method according to any one of claims 1 to 4 when executed by the processor.

6. A readable storage medium, characterized in that: The readable storage medium stores a token leakage verification program, and when the token leakage verification program is executed by the processor, the steps of the token leakage verification method according to any one of claims 1 to 4 are implemented.

Images