An offline identity authentication method based on synchronized seeds

Abstract

The present invention discloses an offline identity authentication method based on synchronized seeds, comprising the following steps: S100: a client generates a seed file for registration at a server, comprising the following steps: S101: a client unique mark is generated according to client features, wherein the client features include a client hardware address, a client name, and a client manufacturer, wherein the client name includes a client product model, and the client hardware address includes a client MAC address; S102: obtaining the current client time, in seconds; S103: generating a current client seed file on a storage medium of the current client; S200: the server synchronizes the seed file; S300: the server generates a dynamic code according to the seed file; S400: the client verifies the validity of the dynamic code. The method has the following beneficial effects: 1. completely offline; 2. dynamically generating a verification code, which increases the timeliness of the password; 3. dynamically generating a seed file, and the key seed has timeliness and uniqueness.

Description

Technical Field

[0001] The invention belongs to the field of data security, and relates to an offline identity authentication method, and in particular to an offline identity authentication method based on synchronization seeds. Background Art

[0002] Identity authentication refers to the confirmation of user identity through certain means. The purpose is to confirm that the user who claims to be a certain identity is the claimed user. In order to ensure system security, identity authentication is required when using important system functions. There are two traditional authentication methods: 1. Online authentication, 2. Offline authentication.

[0003] Online authentication means that the client initiates an authentication request to the server, and sends the account name and password to the server through a network connection. After the server receives the request, it verifies whether the database contains the validity of the account.

[0004] Offline authentication is to establish a local database system and store the username and password in the local database. When the user initiates an identity authentication request, it is directly verified locally whether it is a valid account.

[0005] All of the above methods have certain defects: online authentication relies on the network. When the client cannot connect to the network due to confidentiality requirements and is in an isolated state, online authentication cannot meet the authentication requirements. At the same time, due to the reliance on the network, the entire system is often subject to man-in-the-middle attacks; traditional offline authentication stores accounts and passwords in the local database. Since it is a local database, there is a risk of the entire database being leaked. At the same time, the passwords of the above two methods are fixed. Once leaked, the third party will permanently hold the permissions of the account, which brings great security risks to the system. Summary of the invention

[0006] In view of the technical problems of the prior art, the present invention provides an offline identity authentication method based on synchronization seeds:

[0007] The client generates a seed file based on its own characteristics, and the server stores the seed file. The ways of storing the seed file include but are not limited to local storage / copying and online storage. The server parses the specific information of the seed file and registers the client. When the client registration is completed, the server will dynamically generate random codes at a certain time interval, and the user completes the identity authentication on the client by using these random codes. This method has the following beneficial effects.

[0008] 1. Completely offline: When the client is completely isolated, it does not affect normal use, avoiding man-in-the-middle attacks.

[0009] 2. Dynamically generate verification codes to increase the timeliness of passwords, which can avoid permanent loss of permissions and potential security risks to the system after the password is stolen.

[0010] 3. Dynamically generate seed files. The key seed is time-effective and unique, which increases the cost of third-party cracking.

[0011] The method provided by the present invention comprises the following steps:

[0012] S100: The client generates a seed file for registering on the server, including the following steps:

[0013] S101: Generate a unique client identifier according to client characteristics, wherein the client characteristics include a client hardware address, a client name, and a client manufacturer, wherein the client name includes a client product model, and the client hardware address includes a client MAC address. Step S101 includes the following steps:

[0014] S1011: Obtain the client hardware address, client name, and client manufacturer;

[0015] S1012: Concatenate the client hardware address, the client name, and the client manufacturer in order and use them as the client feature;

[0016] S1013: Using the client hardware address as a key, an encryption algorithm is used to encrypt the client characteristics as a unique identifier of the client;

[0017] S102: Get the current client time in seconds;

[0018] S103: generating a current client seed file on a storage medium of the current client, including the following steps:

[0019] S1031: Write the client's unique identifier into the first line of the seed file;

[0020] S1032: The current client time is written into the second line of the seed file;

[0021] S1033: Setting the validity period of the dynamic key as the client threshold time;

[0022] S1034: Write the client threshold time into the third line of the seed file;

[0023] S200: server synchronizing seed files;

[0024] S300: The server generates a dynamic code according to the seed file;

[0025] S400: The client verifies the validity of the dynamic code.

[0026] Preferably, step S200 includes the following steps:

[0027] S201: storing the seed file in the file directory specified by the server;

[0028] S202: Obtain a set of seed files in the file directory of the server;

[0029] S203: traverse the seed file set, and when an element exists, execute step S204; otherwise, when no element exists, it indicates that the client registration is completed, and execute step S20E;

[0030] S204: Record the current element as a server seed file;

[0031] S205: Read the first line of data in the server seed file and record it as seed_unique flag;

[0032] S206: Read the second line of data in the server seed file and record it as seed_time;

[0033] S207: Read the third line of data in the server seed file and record it as seed_threshold time;

[0034] S208: The server obtains the current time, which is recorded as server_current time, in seconds;

[0035] S209: Calculate the difference between the server_current time and the seed_time, and record it as server_seed_difference time;

[0036] S20A: Determine whether the absolute value of the server_seed_difference time is less than the seed_threshold time. If so, it indicates that the current seed file has not expired, and step S20B is executed. Otherwise, it indicates that the current seed file has expired, and step S20D is executed.

[0037] S20B: Register the server_seed file information in the server database: write seed_unique flag, seed_threshold time and server_seed_difference time;

[0038] S20C: The current seed file registration is completed, the server-side seed file is deleted, and step S203 is executed;

[0039] S20D: Do not register the current seed file, delete the server_seed file, and execute step S203;

[0040] S20E: Client registration is completed.

[0041] Preferably, step S300 includes the following steps:

[0042] S301: Read the seed file of the specified client from the server database, and obtain and record it as code_unique flag, code_threshold time and code_difference time respectively;

[0043] S302: Get the current server time and record it as code_server time, in seconds;

[0044] S303: Calculate the difference between code_server time and code_difference time and record it as code_actual time;

[0045] S304: the quotient of the code_actual time divided by the code_threshold time is rounded to an integer, and recorded as the code_valid time;

[0046] S305: Use an encryption algorithm to encrypt the code_validity time and record it as code_ciphertext, and the key is code_unique flag;

[0047] S306: Encode the code_ciphertext using a coding algorithm and record it as code_code;

[0048] S307: Obtain the last 6 bytes of the code_code and record it as code_dynamic code.

[0049] Preferably, step S400 includes the following steps:

[0050] S401: Determine whether a seed file exists on the client. If yes, execute step S402; otherwise, execute step S417;

[0051] S402: Record the current seed file as verification_seed file, read the first line of data in the verification_seed file, and record it as verification_unique flag;

[0052] S403: Record the client unique identifier generated by the current client feature as actual_unique identifier;

[0053] S404: Determine whether the actual_unique_flag is equal to the verification_unique_flag. If so, it indicates that the current seed file is valid, and execute step S405; otherwise, execute step S417;

[0054] S405: Read the second line of data in the verification_seed file and record it as verification_time;

[0055] S406: Read the third line of data in the verification_seed file and record it as verification_threshold time;

[0056] S407: Get local time, record as verification_current time;

[0057] S408: rounding the quotient of verification_current time divided by verification_threshold time, and recording it as the first valid time;

[0058] S409: Verify_valid time - 1, the result is recorded as the second valid time;

[0059] S40A: Verify_valid time + 1, and the result is recorded as the third valid time;

[0060] S40B: Encrypt the first valid time using an encryption algorithm and record it as the first encryption time, and the key is the verification_unique flag;

[0061] S40C: Encode the first encryption time using the encoding algorithm and record it as the first encoding time;

[0062] S40D: Obtain the last 6 bytes of the first encoding time and record them as the first verification code;

[0063] S40E: Determine whether the first verification code is equal to the code_dynamic code, if yes, execute step S418, otherwise, execute step S40F;

[0064] S40F: Encrypt the second valid time using an encryption algorithm and record it as the second encryption time, and the key is verification_unique flag;

[0065] S410: Encode the second encryption time using the encoding algorithm and record it as the second encoding time;

[0066] S411: Obtain the last 6 bytes of the second encoding time and record them as the second verification code;

[0067] S412: Determine whether the second verification code is equal to the code_dynamic code, if yes, execute step S418, otherwise, execute step S413;

[0068] S413: Encrypt the third valid time using an encryption algorithm and record it as the third encrypted time, and the key is the verification_unique flag;

[0069] S414: Encode the third encryption time using the encoding algorithm and record it as the third encoding time;

[0070] S415: Obtain the last 6 bytes of the third encoding time and record them as the third verification code;

[0071] S416: Determine whether the third verification code is equal to the code_dynamic code, if yes, execute step S418, otherwise, execute step S417;

[0072] S417: The dynamic code verification fails, the identity authentication fails, the system is exited and the process ends;

[0073] S418: The dynamic code verification is passed, the identity authentication is successful, and entry into the system is allowed and the process ends.

[0074] Preferably, the client feature in step S1012 is a unique client identifier generated by concatenating any combination of the client hardware address, the client name, and the client manufacturer, each corresponding to the first line of the seed file. BRIEF DESCRIPTION OF THE DRAWINGS

[0075] Figure 1 The overall flow chart of the method provided by the present invention;

[0076] Figure 2 A specific flow chart of synchronizing seed files on the server side in the method provided by the present invention;

[0077] Figure 3 This is a specific flow chart of the client verifying the validity of the dynamic code in the method provided by the present invention. DETAILED DESCRIPTION

[0078] Figure 1 The overall flow chart of the method provided by the present invention is shown. Figure 1 As shown, the method of the present invention comprises the following steps:

[0079] S100: The client generates a seed file for registering on the server, including the following steps:

[0080] S101: Generate a unique client identifier according to client characteristics, wherein the client characteristics include a client hardware address, a client name, and a client manufacturer, wherein the client name includes a client product model, and the client hardware address includes a client MAC address. Step S101 includes the following steps:

[0081] S1011: Obtain the client hardware address, client name, and client manufacturer;

[0082] S1012: Concatenate the client hardware address, the client name, and the client manufacturer in order and use them as the client feature;

[0083] It should be understood that the client feature in step S1012 is generated by splicing any combination of the client hardware address, the client name and the client manufacturer, and is not limited to the order of the client hardware address, the client name and the client manufacturer in this embodiment.

[0084] S1013: Using the client hardware address as a key, the HmacSHA1 algorithm is used to encrypt the client characteristics as a unique identifier of the client;

[0085] It should be understood that the HmacSHA1 algorithm is used for encryption in the embodiment provided by the present invention, but the method provided by the present invention is not limited to using the HmacSHA1 algorithm for encryption, and the same shall apply hereinafter.

[0086] S102: Get the current client time in seconds;

[0087] S103: The client calls the file generation API to generate a current client seed file on the storage medium of the current client.

[0088] It should be understood that the embodiment provided by the present invention adopts the file generation API to generate the seed file, but the method provided by the present invention is not limited to the method of adopting the file generation API.

[0089] Step S103 includes the following steps:

[0090] S1031: The client calls the file writing API and writes the client's unique identifier in the first line of the seed file;

[0091] It should be understood that the embodiment provided by the present invention adopts the write file API to write data in the seed file, but the method provided by the present invention is not limited to the method of adopting the write file API, and the same shall apply below.

[0092] S1032: The client calls the file writing API and writes the current client time in the second line of the seed file;

[0093] S1033: Setting the validity period of the dynamic key as the client threshold time;

[0094] S1034: The client calls the write file API and writes the client threshold time in the third line of the seed file;

[0095] As mentioned above, since the client characteristics in step S1012 are generated by splicing any combination of the client hardware address, the client name and the client manufacturer, it is not limited to the sequential splicing of the client hardware address, the client name and the client manufacturer in this embodiment. Correspondingly, the client hardware address, the client name and the client manufacturer spliced ​​after any combination should each correspond to the client unique mark of the first line of the seed file. For example, in the seed file corresponding to the client characteristics generated by the sequential combination of the client name, the client manufacturer and the client hardware address, the client unique mark of the first line is the client name, the client manufacturer and the client hardware address, and so on.

[0096] S200: The server synchronizes the seed file.

[0097] Figure 2 FIG. 2 shows a specific flow chart of the server-side synchronization of seed files in the method provided by the present invention. Figure 2 As shown, step S200 includes the following steps:

[0098] S201: storing the seed file in the file directory specified by the server;

[0099] S202: The server calls the file directory acquisition API to obtain a set of seed files in the file directory of the server;

[0100] It should be understood that the embodiment provided by the present invention adopts the method of obtaining the file directory API to obtain the seed file set in the file directory, but the method provided by the present invention is not limited to the method of obtaining the file directory API, and the same applies below.

[0101] S203: traverse the seed file set, and when an element exists, execute step S204; otherwise, when no element exists, it indicates that the client registration is completed, and execute step S20E;

[0102] S204: Record the current element as a server seed file;

[0103] S205: The server calls the file reading API to read the first line of data in the server seed file, which is recorded as seed_unique flag;

[0104] S206: The server calls the file reading API to read the second line of data in the server seed file, which is recorded as seed_time;

[0105] S207: The server calls the file reading API to read the third line of data in the server seed file, which is recorded as seed_threshold time;

[0106] S208: The server obtains the current time, which is recorded as server_current time, in seconds;

[0107] S209: Calculate the difference between the server_current time and the seed_time, and record it as server_seed_difference time;

[0108] S20A: Determine whether the absolute value of the server_seed_difference time is less than the seed_threshold time. If so, it indicates that the current seed file has not expired, and step S20B is executed. Otherwise, it indicates that the current seed file has expired, and step S20D is executed.

[0109] S20B: Register the server_seed file information in the server database: write seed_unique flag, seed_threshold time and server_seed_difference time;

[0110] S20C: The current seed file registration is completed, and the file deletion API is called to delete the server-side seed file, and step S203 is executed;

[0111] It should be understood that the embodiment provided by the present invention adopts a file deletion API to delete seed files, but the method provided by the present invention is not limited to the method using the file deletion API, and the same shall apply below.

[0112] S20D: Do not register the current seed file, call the file deletion API to delete the server-side seed file, and execute step S203;

[0113] S20E: Client registration is completed.

[0114] S300: The server generates a dynamic code according to the seed file; step S300 includes the following steps:

[0115] S301: Read the seed file of the specified client from the server database, and obtain and record it as code_unique flag, code_threshold time and code_difference time respectively;

[0116] S302: Get the current server time and record it as code_server time, in seconds;

[0117] S303: Calculate the difference between code_server time and code_difference time and record it as code_actual time;

[0118] S304: the quotient of the code_actual time divided by the code_threshold time is rounded to an integer, and recorded as the code_valid time;

[0119] S305: Use HmacSHA1 algorithm to encrypt the code_validity time and record it as code_ciphertext, and the key is code_unique flag;

[0120] S306: Encode the code_ciphertext using the Base64 encoding algorithm and record it as code_code;

[0121] It should be understood that the Base64 encoding algorithm is used for encoding in the embodiment provided by the present invention, but the method provided by the present invention is not limited to using the Base64 encoding algorithm for encoding, and the same shall apply hereinafter.

[0122] S307: Obtain the last 6 bytes of the code_code and record it as code_dynamic code.

[0123] S400: The client verifies the validity of the dynamic code.

[0124] Figure 3 The specific flow chart of the client verifying the validity of the dynamic code in the method provided by the present invention is shown. Figure 3 As shown, step S400 includes the following steps:

[0125] S401: Determine whether a seed file exists on the client. If yes, execute step S402; otherwise, execute step S417;

[0126] S402: The current seed file is recorded as verification_seed file, and the client calls the file reading API to read the first line of data of the verification_seed file and record it as verification_unique flag;

[0127] S403: Record the client unique identifier generated by the current client feature as actual_unique identifier;

[0128] S404: Determine whether the actual_unique_flag is equal to the verification_unique_flag. If so, it indicates that the current seed file is valid, and execute step S405; otherwise, execute step S417;

[0129] S405: The client calls the file reading API to read the second line of data in the verification_seed file and records it as verification_time;

[0130] S406: The client calls the file reading API to read the third line of data in the verification_seed file, which is recorded as the verification_threshold time;

[0131] S407: Get local time, record as verification_current time;

[0132] S408: rounding the quotient of verification_current time divided by verification_threshold time, and recording it as the first valid time;

[0133] S409: Verify_valid time - 1, the result is recorded as the second valid time;

[0134] S40A: Verify_valid time+1, and the result is recorded as the third valid time;

[0135] S40B: Use HmacSHA1 algorithm to encrypt the first valid time and record it as the first encrypted time, and the key is verification_unique flag;

[0136] S40C: Encode the first encryption time using the Base64 encoding algorithm and record it as the first encoding time;

[0137] S40D: Obtain the last 6 bytes of the first encoding time and record them as the first verification code;

[0138] S40E: Determine whether the first verification code is equal to the code_dynamic code, if yes, execute step S418, otherwise, execute step S40F;

[0139] S40F: Use HmacSHA1 algorithm to encrypt the second valid time and record it as the second encrypted time, and its key is verification_unique flag;

[0140] S410: Encode the second encryption time using the Base64 encoding algorithm and record it as the second encoding time;

[0141] S411: Obtain the last 6 bytes of the second encoding time and record them as the second verification code;

[0142] S412: Determine whether the second verification code is equal to the code_dynamic code, if yes, execute step S418, otherwise, execute step S413;

[0143] S413: Use HmacSHA1 algorithm to encrypt the third valid time and record it as the third encrypted time, and the key is verification_unique flag;

[0144] S414: Encode the third encryption time using the Base64 encoding algorithm and record it as the third encoding time;

[0145] S415: Obtain the last 6 bytes of the third encoding time and record them as the third verification code;

[0146] S416: Determine whether the third verification code is equal to the code_dynamic code, if yes, execute step S418, otherwise, execute step S417;

[0147] S417: The dynamic code verification fails, the identity authentication fails, the system is exited and the process ends;

[0148] S418: The dynamic code verification is passed, the identity authentication is successful, and entry into the system is allowed and the process ends.

[0149] The method provided by the present invention solves the technical problem that there is no offline identity authentication method based on synchronization seeds in the prior art.

[0150] It should be understood that the present invention is not limited to the above examples. For those skilled in the art, improvements or changes can be made based on the above description. All these improvements and changes should fall within the scope of protection of the claims attached to the present invention.

Claims

1. An offline identity authentication method based on synchronized seeds, characterized in that The following steps are involved: S100: The client generates a seed file for registering on the server, including the following steps: S101: Generate a unique client identifier according to client characteristics, wherein the client characteristics include a client hardware address, a client name, and a client manufacturer, wherein the client name includes a client product model, and the client hardware address includes a client MAC address. Step S101 includes the following steps: S1011: Obtain the client hardware address, client name, and client manufacturer; S1012: Concatenate the client hardware address, the client name, and the client manufacturer in order and use them as the client feature; S1013: Using the client hardware address as a key, an encryption algorithm is used to encrypt the client characteristics as a unique identifier of the client; S102: Get the current client time in seconds; S103: generating a current client seed file on a storage medium of the current client, including the following steps: S1031: Write the client's unique identifier into the first line of the seed file; S1032: The current client time is written into the second line of the seed file; S1033: Setting the validity period of the dynamic key as the client threshold time; S1034: Write the client threshold time into the third line of the seed file; S200: server synchronizing seed files; S300: The server generates a dynamic code according to the seed file. Step S300 includes the following steps: S301: Read the seed file of the specified client from the server database, and obtain and record it as code_unique flag, code_threshold time and code_difference time respectively; S302: Get the current server time and record it as code_server time, in seconds; S303: Calculate the difference between code_server time and code_difference time and record it as code_actual time; S304: the quotient of the code_actual time divided by the code_threshold time is rounded to an integer, and recorded as the code_valid time; S305: Use an encryption algorithm to encrypt the code_validity time and record it as code_ciphertext, and the key is code_unique flag; S306: Encode the code_ciphertext using a coding algorithm and record it as code_code; S307: Obtain the last 6 bytes of code_code and record it as code_dynamic code; S400: The client verifies the validity of the dynamic code.

2. According to claim 1, an offline identity authentication method based on synchronization seed is characterized in that: Step S200 includes the following steps: S201: storing the seed file in the file directory specified by the server; S202: Obtain a set of seed files in the file directory of the server; S203: traverse the seed file set, and when an element exists, execute step S204; otherwise, when no element exists, it indicates that the client registration is completed, and execute step S20E; S204: Record the current element as a server seed file; S205: Read the first line of data in the server seed file and record it as seed_unique flag; S206: Read the second line of data in the server seed file and record it as seed_time; S207: Read the third line of data in the server seed file and record it as seed_threshold time; S208: The server obtains the current time, which is recorded as server_current time, in seconds; S209: Calculate the difference between the server_current time and the seed_time, and record it as server_seed_difference time; S20A: Determine whether the absolute value of the server_seed_difference time is less than the seed_threshold time. If so, it indicates that the current seed file has not expired, and step S20B is executed. Otherwise, it indicates that the current seed file has expired, and step S20D is executed. S20B: Register the server_seed file information in the server database: write seed_unique flag, seed_threshold time and server_seed_difference time; S20C: The current seed file registration is completed, the server-side seed file is deleted, and step S203 is executed; S20D: Do not register the current seed file, delete the server_seed file, and execute step S203; S20E: Client registration is completed.

3. According to claim 1, an offline identity authentication method based on synchronization seed is characterized in that: Step S400 includes the following steps: S401: Determine whether a seed file exists on the client. If yes, execute step S402; otherwise, execute step S417; S402: Record the current seed file as verification_seed file, read the first line of data in the verification_seed file, and record it as verification_unique flag; S403: Record the client unique identifier generated by the current client feature as actual_unique identifier; S404: Determine whether the actual_unique_flag is equal to the verification_unique_flag. If so, it indicates that the current seed file is valid, and execute step S405; otherwise, execute step S417; S405: Read the second line of data in the verification_seed file and record it as verification_time; S406: Read the third line of data in the verification_seed file and record it as verification_threshold time; S407: Get local time, record as verification_current time; S408: rounding the quotient of verification_current time divided by verification_threshold time, and recording it as the first valid time; S409: Verify_valid time - 1, the result is recorded as the second valid time; S40A: Verify_valid time+1, and the result is recorded as the third valid time; S40B: Encrypt the first valid time using an encryption algorithm and record it as the first encryption time, and the key is verification_unique flag; S40C: Encode the first encryption time using the encoding algorithm and record it as the first encoding time; S40D: Obtain the last 6 bytes of the first encoding time and record them as the first verification code; S40E: Determine whether the first verification code is equal to the code_dynamic code, if yes, execute step S418, otherwise, execute step S40F; S40F: Encrypt the second valid time using an encryption algorithm and record it as the second encryption time, and the key is verification_unique flag; S410: Encode the second encryption time using the encoding algorithm and record it as the second encoding time; S411: Obtain the last 6 bytes of the second encoding time and record them as the second verification code; S412: Determine whether the second verification code is equal to the code_dynamic code, if yes, execute step S418, otherwise, execute step S413; S413: Encrypt the third valid time using an encryption algorithm and record it as the third encrypted time, and the key is the verification_unique flag; S414: Encode the third encryption time using the encoding algorithm and record it as the third encoding time; S415: Obtain the last 6 bytes of the third encoding time and record them as the third verification code; S416: Determine whether the third verification code is equal to the code_dynamic code, if yes, execute step S418, otherwise, execute step S417; S417: The dynamic code verification fails, the identity authentication fails, the system is exited and the process ends; S418: The dynamic code verification is passed, the identity authentication is successful, and entry into the system is allowed and the process ends.

4. According to claim 1, an offline identity authentication method based on synchronization seed is characterized in that: In step S1012, the client feature is generated by combining any combination of the client hardware address, the client name and the client manufacturer, and each corresponds to the client unique identifier in the first line of the seed file.

Images