Method and system for managing mobile phone token on basis of ios platform, and electronic device and storage medium

Abstract

The present application belongs to the technical field of information security authentication. Disclosed are a method and system for managing a mobile phone token on the basis of an iOS platform, and an electronic device and a storage medium. The method specifically comprises: a mobile phone end reading a key encrypted by an official website, saving same in a keychain, decrypting the key to obtain a random code associated with a user, and on the basis of the current time and step size, using an SHA1 algorithm to obtain a dynamic code, wherein the dynamic code is updated every 30 seconds, and if dynamic codes are consistent after comparison, binding is successful; and when the user logs in again, it being necessary to verify the dynamic code to enter a system in addition to inputting a correct account and a correct password, and when the mobile phone end reads the key again, comparing the key with the previous key which is saved in the keychain, and resetting the key into the keychain on the basis of the difference between the two. In the present application, a key is saved in a keychain, so as to avoid data loss and network impacts, and data in the keychain is not lost when an application is exited and restarted or uninstalled and re-installed, and can be used permanently, such that the problems of existing short message service verification codes being attacked and cracked can be satisfactorily solved.

Description

Mobile phone token management method, system, electronic device and storage medium based on iOS platform

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to the Chinese patent application filed with the China Patent Office on December 12, 2023, with application number 202311703147.2 and invention name “A mobile phone token management method based on iOS platform”, the entire contents of which are incorporated by reference into this application. Technical Field

[0003] The present application belongs to the field of information security authentication technology, and specifically relates to a mobile phone token management method, system, electronic device, and storage medium based on the iOS platform. Background Art

[0004] With the increasing number of internet password leaks, passwords alone are no longer a guarantee of true security. In fact, credential leakage has become the biggest security threat to businesses. More and more products are supporting two-factor authentication, also known as two-factor authentication. This requires users to provide an additional factor in addition to their username and password to enhance the security of the authentication process. Common methods include SMS verification codes and biometrics. SMS verification carries the risk of being hacked or intercepted, and sending large amounts of text messages increases business costs. Biometric technology also conflicts with cybersecurity requirements regarding the collection of personal information. To address these issues, hardware dynamic code technology can be introduced for two-factor authentication.

[0005] For example, Chinese patent application CN103259666B discloses a multi-token management system and method for mobile phone tokens. The system includes a mobile phone terminal, a portal website management device, and a verification platform. The portal website management device is connected to the mobile phone terminal and the verification platform, respectively. The mobile phone terminal includes an input module, a token management module, and a display module. The display module displays dynamic passwords for multiple activation tokens and merchant information corresponding to each activation token. This invention replaces the single-token model in mobile phone token management devices, enabling the operation of multiple merchant tokens on a single mobile phone token management device, reducing system redundancy and broadening the application scope of mobile phone tokens.

[0006] For example, the Chinese patent with the authorization announcement number CN104539785B discloses an installation application on IOS and Android mobile phone operating systems. A one-time dynamic password is generated using a mechanism synchronized with the server time, which is valid within a valid time period (30s / 60s) to meet the needs of multi-factor verification in a short period of time. The mobile phone dynamic password generation process has the advantages of being simple to use, highly secure, low-cost, and not requiring the carrying of additional equipment. This invention is to add a one-key release button to the mobile phone token. After the third-party application system pops up a pop-up window with a secondary verification code during the password verification process, it refreshes the one-key release check interface every 3 seconds to check whether the user has used the mobile phone token to initiate a one-key release. If the user presses the one-key release button on the mobile phone token, that is, the user initiates a one-key release request to the mobile phone token server through the mobile phone token client, the mobile phone token server will quickly verify the request after receiving it. Summary of the Invention

[0007] In response to the shortcomings of the existing technology, this application proposes a mobile phone token management method, system, electronic device and storage medium based on the iOS platform. After the user successfully logs in to the official website, the mobile phone token verification is enabled. The server sends an encrypted string based on the account information. The user uses the iOS mobile phone token manager to scan the code to identify the encrypted string and decode it. The decoding obtains the secret. The mobile phone token manager sends a verification time signal, compares the local time with the server time, and uses the SHA1 encryption algorithm according to the current time and step size to obtain a dynamic code. At the same time, the secret is saved in the iOS system CTKeyChain. The user then compares this dynamic code with the server-side dynamic code. A successful comparison means a successful binding. The next time the user logs in and performs key operations, the mobile phone token needs to be verified again. The user can enter the system only after successful verification.

[0008] To achieve the above objectives, this application provides the following technical solutions:

[0009] A mobile phone token management method based on the iOS platform includes the following specific steps:

[0010] Step S1: After the user successfully logs in to the official website, the user starts the mobile phone token verification, and the server sends the encryption string according to the account information;

[0011] Step S2: The user uses the iOS mobile phone token manager to scan the code to identify the encrypted string and decode it to obtain the secret;

[0012] Step S3: The mobile phone token manager sends a verification time signal to compare the local time with the server time;

[0013] Step S4: Based on the current time and step length, the SHA1 encryption algorithm is used to obtain a dynamic code, and the secret is saved to the iOS system CTKeyChain. The user then compares this dynamic code with the server-side dynamic code. If the comparison is successful, the binding is successful;

[0014] Step S5: The next time the user logs in and performs key operations, the user needs to perform a secondary verification with the mobile phone token. The user can enter the system only after successful verification.

[0015] Specifically, the step length in step S4 is 30s.

[0016] Specifically, the specific method of obtaining the dynamic code using the SHA1 encryption algorithm in step S4 is:

[0017] Step S401: Divide the secret data into blocks with a block length of 512 bits;

[0018] Step S402: Set two buffers, buffer1 and buffer2, where buffer1 is marked as A, B, C, D, and E, and buffer2 is marked as H0, H1, H2, H3, and H4;

[0019] Step S403: Fill the buffer marked as H;

[0020] Step S404: For the blocks whose length and content do not meet the requirements after the secret data is divided, padding method is used to supplement the data;

[0021] Step S405: Set A=H0, B=H1, C=H2, D=H3, E=H4, update the value in buffer2, and output H0', H1', ​​H2', H3', H4', where H0'=A+H0, H1'=B+H1, H2'=C+H2, H3'=D+H3, H4'=E+H4.

[0022] Specifically, the padding method in step S404 includes: first filling one bit of 1, then filling N bits of 0, and finally filling the length information of the 64-bit block length M, satisfying the constraint conditions: (L M +1+N+64)%512=0, where L M Indicates the length of the block length M.

[0023] Specifically, the specific implementation steps of CTKeyChain in step S4 are:

[0024] Step S411: Create a Category file NSObject+CTKeyChain of the base class NSObject;

[0025] Step S412: Declare data storage and retrieval related methods through the classification file NSObject+CTKeyChain, and define the data storage method +setDataWithKey:NSString*key and the data retrieval method +NSString*dataWithKey:NSString*key in the implementation interval;

[0026] Step S413: The classification file NSObject+CTKeyChain obtains the Ivars value of the system keychain keyChain structure through the runtime reflection mechanism, defines this value as key, and then assigns a value to the key. Then, all properties and methods of the structure are traversed to obtain each value, and then KVC calls the keyChain private method to store the data;

[0027] Step S414: Data is stored through the declaration and definition of the data storage method + setDataWithKey:NSString*key.

[0028] Specifically, the key operations in step S5 include logging in and paying.

[0029] A mobile phone token management system based on the iOS platform, including: an initial login module, an identification and decoding module, a time verification module, a dynamic code generation and comparison module, and a secondary verification module;

[0030] The first login module is used to enable mobile phone token verification after the user successfully logs in to the official website, and the server sends an encrypted string based on the account information;

[0031] The identification and decoding module is used for users to scan the code with the iOS mobile phone token manager to identify the encrypted string and decode it to obtain the secret;

[0032] The time verification module is used for the mobile phone token manager to send a verification time signaling to compare the local time with the server time;

[0033] The dynamic code generation and comparison module is used to generate a dynamic code based on the current time and step length using the SHA1 encryption algorithm, and save the secret to the iOS system CTKeyChain. The user then compares this dynamic code with the server-side dynamic code. If the comparison is successful, the binding is successful.

[0034] The secondary verification module is used for the next time the user logs in and performs key operations. The user needs to perform secondary verification with a mobile phone token. Only after successful verification can the user enter the system.

[0035] Specifically, the dynamic code generation and comparison module includes a dynamic code generation unit and a dynamic code comparison unit.

[0036] The dynamic code generating unit is used to obtain the dynamic code using the SHA1 encryption algorithm according to the current time and step length;

[0037] The dynamic code comparison unit is used to save the secret to the iOS system CTKeyChain. The user uses this dynamic code to compare with the server-side dynamic code. If the comparison is successful, the binding is successful.

[0038] An electronic device includes a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of a mobile phone token management method based on the iOS platform when executing the computer program.

[0039] A computer-readable storage medium stores computer instructions, which, when executed, execute the steps of a mobile phone token management method based on the iOS platform.

[0040] Compared with the prior art, the present invention has the following advantages:

[0041] 1. This application proposes a mobile phone token management system based on the iOS platform, and optimizes and improves the architecture, operation steps and processes. The system has the advantages of simple process, low investment and operation costs, and low production work costs.

[0042] 2. This application proposes a mobile phone token management method based on the iOS platform. Mobile phone token authentication is a very effective method to prevent attacks. Compared with SMS verification codes, mobile phone tokens can save corporate costs. They are bound once and can be used permanently. They are extremely stable. Mobile phone tokens are based on a time-based one-time password algorithm. There is no need to request data and they are not affected by the network at the time. They can scan all tokens in the dynamic token manager of this device, automatically match them with accounts, and automatically fill in tokens, making the operation more convenient.

[0043] 3. This application proposes a mobile phone token management method based on the iOS platform, which greatly reduces the labor cost of API development, shortens development time, and thus improves software development efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] FIG1 is a flow chart of a mobile phone token management method based on the iOS platform of this application;

[0045] Figure 2 is a flowchart of a SMS secondary verification solution for a mobile phone token management method based on the iOS platform of this application;

[0046] FIG3 is a flowchart of a mobile phone dynamic token solution for a mobile phone token management method based on the iOS platform of the present application;

[0047] FIG4 is an architecture diagram of a mobile phone token management system based on the iOS platform of this application;

[0048] FIG5 is a diagram of an electronic device for a mobile phone token management method based on the iOS platform of the present application. DETAILED DESCRIPTION

[0049] In order to make the technical means, creative features, objectives and effects achieved by this application easy to understand, it should be noted that in the description of this application, the terms "center", "up", "down", "left", "right", "vertical", "horizontal", "inside", "outside" and the like indicate directions or positional relationships based on the directions or positional relationships shown in the accompanying drawings. They are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific direction, be constructed and operated in a specific direction. Therefore, they cannot be understood as limitations on this application. In addition, the terms "No. 1", "No. 2" and "No. 3" are used for descriptive purposes only and cannot be understood as indicating or implying relative importance. The following further describes this application in conjunction with specific implementation methods.

[0050] Example 1

[0051] Referring to Figures 1 to 3, this application provides an embodiment: a mobile phone token management method based on the iOS platform, comprising the following specific steps:

[0052] Step S1: After the user successfully logs in to the official website, the user starts the mobile phone token verification, and the server sends the encryption string according to the account information;

[0053] Step S2: The user uses the iOS mobile phone token manager to scan the code to identify the encrypted string and decode it to obtain the secret;

[0054] Step S3: The mobile phone token manager sends a verification time signal to compare the local time with the server time;

[0055] Step S4: Based on the current time and step length, the SHA1 encryption algorithm is used to obtain a dynamic code, and the secret is saved to the iOS system CTKeyChain. The user then compares this dynamic code with the server-side dynamic code. If the comparison is successful, the binding is successful;

[0056] Step S5: The next time the user logs in and performs key operations, the user needs to perform a secondary verification with the mobile phone token. The user can enter the system only after successful verification.

[0057] Traditional secondary verification solutions using SMS verification codes have several drawbacks: 1) There's a risk of malicious swiping of SMS verification codes; 2) SMS verification code delivery rates are problematic. Currently, no SMS verification code platform can guarantee 100% delivery rates; 3) Due to security vulnerabilities, SMS messages may be intercepted by network providers; and 4) As business grows, SMS volume increases significantly, increasing enterprise SMS costs.

[0058] The step length in step S4 is 30 seconds.

[0059] The specific method of obtaining the dynamic code using the SHA1 encryption algorithm in step S4 is:

[0060] Step S401: Divide the secret data into blocks with a block length of 512 bits;

[0061] Step S402: Set two buffers, buffer1 and buffer2, where buffer1 is marked as A, B, C, D, and E, and buffer2 is marked as H0, H1, H2, H3, and H4;

[0062] The unit of the two buffers is word. A word is a 32-bit string that can be represented as a sequence of 8 hexadecimal characters, for example: A103FE23.

[0063] Step S403: Fill the buffer marked as H;

[0064] Fill the buffer marked H with the following values: H0: 0x67452301; H1: 0xEFCDAB89; H2: 0x98BADCFE; H3: 0x10325476; H4: 0xC3D2E1F0.

[0065] Step S404: For the blocks whose length and content do not meet the requirements after the secret data is divided, padding method is used to supplement the data;

[0066] Step S405: Set A=H0, B=H1, C=H2, D=H3, E=H4, update the value in buffer2, and output H0', H1', ​​H2', H3', H4', where H0'=A+H0, H1'=B+H1, H2'=C+H2, H3'=D+H3, H4'=E+H4.

[0067] The padding method in step S404 includes: first filling one bit of 1, then filling N bits of 0, and finally filling the length information of the 64-bit block length M, satisfying the constraint conditions: (L M+1+N+64)%512=0, where L M Indicates the length of the block length M.

[0068] The specific implementation steps of CTKeyChain in step S4 are:

[0069] Step S411: Create a Category file NSObject+CTKeyChain of the base class NSObject;

[0070] Step S412: Declare data storage and retrieval related methods through the classification file NSObject+CTKeyChain, and define the data storage method +setDataWithKey:NSString*key and the data retrieval method +NSString*dataWithKey:NSString*key in the implementation interval;

[0071] Step S413: The classification file NSObject+CTKeyChain obtains the Ivars value of the system keychain keyChain structure through the runtime reflection mechanism, defines this value as key, and then assigns a value to the key. Then, all properties and methods of the structure are traversed to obtain each value, and then KVC calls the keyChain private method to store the data;

[0072] Step S414: Data is stored through the declaration and definition of the data storage method + setDataWithKey:NSString*key.

[0073] The key operations in step S5 include login and payment.

[0074] Example 2

[0075] Please refer to FIG4 , another embodiment provided by the present application: a mobile phone token management system based on the iOS platform, comprising: an initial login module, an identification and decoding module, a time verification module, a dynamic code generation and comparison module, and a secondary verification module;

[0076] The first login module is used to enable mobile phone token verification after the user successfully logs in to the official website, and the server sends an encrypted string based on the account information;

[0077] The identification and decoding module is used for users to scan the code with the iOS mobile phone token manager to identify the encrypted string and decode it to obtain the secret;

[0078] The time verification module is used for the mobile phone token manager to send a verification time signaling to compare the local time with the server time;

[0079] The dynamic code generation and comparison module is used to obtain a dynamic code based on the current time and step length using the SHA1 encryption algorithm, and save the secret to the iOS system CTKeyChain. The user then compares this dynamic code with the server-side dynamic code. A successful comparison means successful binding.

[0080] The secondary verification module is used for the next time the user logs in and performs key operations. The user needs to perform secondary verification with a mobile phone token. Only after successful verification can the user enter the system.

[0081] The dynamic code generation and comparison module includes a dynamic code generation unit and a dynamic code comparison unit.

[0082] The dynamic code generating unit is used to obtain the dynamic code using the SHA1 encryption algorithm according to the current time and step length;

[0083] The dynamic code comparison unit is used to save the secret to the iOS system CTKeyChain. The user uses this dynamic code to compare with the server-side dynamic code. If the comparison is successful, the binding is successful.

[0084] Example 3

[0085] Please refer to FIG5 , which shows an electronic device including a memory and a processor. The memory stores a computer program, and the processor implements the steps of a mobile phone token management method based on the iOS platform when executing the computer program.

[0086] A computer-readable storage medium stores computer instructions, which, when executed, execute the steps of a mobile phone token management method based on the iOS platform.

[0087] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0088] The present application is described with reference to the flow chart and / or block diagram of the method, device (system), and computer program product according to the embodiment of the present application. It should be understood that each flow process and / or box in the flow chart and / or block diagram and the combination of the flow process and / or box in the flow chart and / or block diagram can be realized by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processing machine or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for realizing the function specified in one flow chart flow or multiple flows and / or one box or multiple boxes of the block diagram.

[0089] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0090] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0091] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of the present application, ordinary technicians in this field can also make many forms without departing from the purpose of the present application and the scope of protection of the claims, all of which are protected by the present application.

[0092] Finally: The above description is only an optional embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should be included in the scope of protection of the present application.

Claims

1. A mobile phone token management method based on iOS platform, characterized in that: The specific steps include: Step S1: After the user successfully logs in to the official website, the user starts the mobile phone token verification, and the server sends the encrypted string according to the account information; Step S2: The user uses the iOS mobile phone token manager to scan the code to identify the encrypted string and decode it to obtain the secret; Step S3: The mobile phone token manager sends a verification time signal to compare the local time with the server time; Step S4: According to the current time and step length, the dynamic code is obtained by using the SHA1 encryption algorithm, and the secret is saved to the iOS system CTKeyChain. The user then compares the dynamic code with the server-side dynamic code. If the comparison is successful, the binding is successful. Step S5: The next time the user logs in and performs key operations, the user needs to perform a second verification with the mobile phone token, and can enter the system only after successful verification.

2. The method for managing mobile phone tokens based on iOS platform as claimed in claim 1, characterized in that: The step length in step S4 is 30 seconds.

3. The method for managing mobile phone tokens based on iOS platform as claimed in claim 2, characterized in that: The specific method of obtaining the dynamic code using the SHA1 encryption algorithm in step S4 is: Step S401: Divide the secret data into blocks, with the block length being 512 bits; Step S402: Set two buffers, buffer1 and buffer2, where buffer1 is marked as A, B, C, D and E, and buffer2 is marked as H0, H1, H2, H3 and H4; Step S403: Fill the bbuffer marked as H; Step S404: For the blocks whose length and content do not meet the requirements after the secret data is divided into blocks, the padding method is used to supplement the data; Step S405: Set A=H0, B=H1, C=H2, D=H3, E=H4, update the value in buffer2, and output H0', H1', ​​H2', H3', H4', where H0'=A+H0, H1'=B+H1, H2'=C+H2, H3'=D+H3, H4'=E+H4.

4. The method for managing mobile phone tokens based on iOS platform as claimed in claim 3, characterized in that: The padding method in step S404 includes: first padding one bit of 1, then padding N bits of 0, and finally padding the length information of the 64-bit block length M, satisfying the constraint condition: (L M +1+N+64)%512=0, where L M Indicates the length of the block length M.

5. The method for managing mobile phone tokens based on iOS platform as claimed in claim 4, characterized in that: The specific implementation steps of CTKeyChain in step S4 are: Step S411: Create a Category file NSObject+CTKeyChain of the base class NSObject; Step S412: Declare data storage and retrieval related methods through the classification file NSObject+CTKeyChain, and define the data storage method +setDataWithKey:NSString*key and the data retrieval method +NSString*dataWithKey:NSString*key in the implementation interval; Step S413: The classification file NSObject+CTKeyChain obtains the Ivars value of the system keychain keyChain structure through the runtime reflection mechanism, defines this value as key, assigns value to the key, and then traverses all the properties and methods of the structure to obtain each value, and then kvc calls the keyChain private method to store data; Step S414: Data is stored through the declaration and definition of the data storage method + setDataWithKey:NSString*key.

6. The method for managing mobile phone tokens based on iOS platform as claimed in claim 5, characterized in that: The key operations in step S5 include login and payment.

7. A mobile phone token management system based on iOS platform, which is implemented based on the mobile phone token management method based on iOS platform described in any one of claims 1-6, characterized in that: The system includes: an initial login module, an identification and decoding module, a time verification module, a dynamic code generation and comparison module, and a secondary verification module; The first login module is used to enable mobile phone token verification after the user successfully logs in to the official website, and the server sends an encrypted string based on the account information; The identification and decoding module is used for the user to scan the code with the iOS mobile phone token manager to identify the encrypted string and decode it to obtain the secret; The time verification module is used for the mobile phone token manager to send a verification time signal to compare the local time with the server time; The dynamic code generation and comparison module is used to obtain the dynamic code according to the current time and step length using the SHA1 encryption algorithm, and save the secret to the iOS system CTKeyChain. The user then compares the dynamic code with the server-side dynamic code. If the comparison is successful, the binding is successful. The secondary verification module is used for the next time the user logs in. When performing key operations, the user needs a mobile phone token for secondary verification. The user can enter the system only after successful verification.

8. The mobile phone token management system based on iOS platform as claimed in claim 7, characterized in that: The dynamic code generation and comparison module includes a dynamic code generation unit and a dynamic code comparison unit. The dynamic code generation unit is used to obtain the dynamic code using the SHA1 encryption algorithm according to the current time and step length; The dynamic code comparison unit is used to save the secret to the iOS system CTKeyChain. The user compares the dynamic code with the server-side dynamic code. If the comparison is successful, the binding is successful.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the mobile phone token management method based on the iOS platform described in any one of claims 1-6 are implemented.

10. A computer-readable storage medium, characterized in that: Computer instructions are stored thereon, and when the computer instructions are executed, the steps of the mobile phone token management method based on the iOS platform described in any one of claims 1-6 are executed.

Images