A mobile phone token management method and system based on an iOS platform

Abstract

The application discloses a kind of mobile phone token management method based on iOS platform, belong to information security authentication technical field, its method specifically includes: mobile phone end reads the key after official website encryption, and save to keychain, key decryption obtains a random code associated with user, according to current time and step length, dynamic code is obtained using SHA1 algorithm, dynamic code 30 seconds update once, dynamic code comparison is consistent, and it is bound successfully;When user logs in again, in addition to inputting correct account password, dynamic code also needs to be verified to enter into system, mobile phone end reads key again, compare the key previously saved in keychain, and reset to keychain according to the difference between the two, the key is saved in keychain in the application, and data will not be lost, will not be affected by network, APP exits restart or uninstallation and reinstallation, the data in keychain will not be lost, and can be used permanently, can well solve the problem that existing mobile phone SMS verification code exists attack, blast.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of information security authentication, and particularly relates to a mobile phone token management method based on an iOS platform. BACKGROUND

[0002] With frequent password leakage events on the Internet, passwords alone cannot guarantee real security. In fact, credential leakage has become the biggest security threat to enterprises, and more and more products have begun to support two-factor authentication, which is also called two-factor authentication. Two-factor authentication requires users to provide an additional factor in addition to a username and password to enhance the security of the identity authentication process. Common examples include mobile phone SMS verification codes and biometric identification. Mobile phone SMS verification has two problems: one is the risk of being attacked or monitored, and the other is that sending a large number of mobile phone SMS messages increases the cost of enterprises. Biometric identification technology also conflicts with the requirements of network security and safety in terms of personal information collection. In the face of these problems, hardware dynamic code technology can be introduced for two-factor security authentication.

[0003] A mobile phone token multi-token management system and method are disclosed in Chinese Patent No. CN103259666B. 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. The mobile phone terminal includes an input module, a token management module, and a display module. The display module displays dynamic passwords for multiple active tokens and merchant information corresponding to each active token. The mobile phone token multi-token management system and method change the single token mode in the mobile phone token management device, allowing multiple merchant tokens to run on one mobile phone token management device, reducing system redundancy, and expanding the application range of mobile phone tokens.

[0004] A method for installing an application program on an IOS and Android mobile phone operating system is disclosed in Chinese Patent No. CN104539785B. A one-time dynamic password is generated using a server time synchronization mechanism, which is valid for a certain period of time (30s / 60s) to meet the needs of multi-factor authentication within a short period of time. The mobile phone dynamic password generation process has the advantages of simplicity, high security, low cost, and no need to carry additional equipment. The invention adds a one-key release button to the mobile phone token. After the secondary verification code pop-up window is popped up in the password verification link of the third-party application system, the one-key release check interface is refreshed every 3 seconds to check whether the user initiates the one-key release with the mobile phone token. If the user presses the one-key release button on the mobile phone token, 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 receives the request and quickly verifies it. SUMMARY

[0005] In view of the deficiencies of the prior art, the application provides a mobile phone token management method based on an iOS platform, after a user logs in successfully on an official website, the user starts mobile phone token verification, a server issues an encrypted string according to account information, the user scans and identifies the encrypted string by using an iOS mobile phone token manager and decodes the encrypted string, a secret is obtained by decoding, the mobile phone token manager sends a check time signaling, compares local time with server time, according to current time and a step, a dynamic code is obtained by using a SHA1 encryption algorithm, the secret is saved to an iOS end system CTKeyChain, then the user compares the dynamic code with a server end dynamic code, if the comparison is successful, the binding is successful, next time the user logs in, when a key operation is performed, the mobile phone token needs to be verified again, if the verification is successful, the user can enter the system.

[0006] To achieve the above object, the application provides the following technical scheme.

[0007] A mobile phone token management method based on an iOS platform comprises the following specific steps.

[0008] Step S1: after a user logs in successfully on an official website, the user starts mobile phone token verification, a server issues an encrypted string according to account information;

[0009] Step S2: the user scans and identifies the encrypted string by using an iOS mobile phone token manager and decodes the encrypted string, a secret is obtained by decoding;

[0010] Step S3: the mobile phone token manager sends a check time signaling, compares local time with server time;

[0011] Step S4: according to current time and a step, a dynamic code is obtained by using a SHA1 encryption algorithm, the secret is saved to an iOS end system CTKeyChain, then the user compares the dynamic code with a server end dynamic code, if the comparison is successful, the binding is successful;

[0012] Step S5: next time the user logs in, when a key operation is performed, the mobile phone token needs to be verified again, if the verification is successful, the user can enter the system.

[0013] Specifically, the step S4 is that the step length is 30s.

[0014] Specifically, the step S4 is that the specific method for obtaining the dynamic code by using the SHA1 encryption algorithm is that:

[0015] Step S401: secret data is processed by block, the block length is 512bit;

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

[0017] Step S403: Fill the bbuffer marked as H;

[0018] Step S404: For the block of secret data whose length and content do not meet the requirements, use the padding method to supplement data;

[0019] Step S405: Set A=H0, B=H1, C=H2, D=H3, E=H4, update the values in buffer2, and output H0', H1', H2', H3' and H4', wherein H0'=A+H0, H1'=B+H1, H2'=C+H2, H3'=D+H3 and H4'=E+H4.

[0020] Specifically, the padding method in step S404 includes: first filling a bit of 1, then filling N bits of 0, and finally filling the length information of 64 bits of the block length M, which satisfies the constraint condition: (L M +1+N+64)%512=0, wherein L M represents the length of the block length M.

[0021] Specifically, the CTKeyChain in step S4 has the following specific implementation steps:

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

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

[0024] Step S413: The Category file NSObject+CTKeyChain obtains the Ivars value of the system keychain keyChain structure body through the runtime reflection mechanism, defines this value as key, then assigns a value to key, then traverses all attributes and methods of the structure body, obtains each value, and then calls the keyChain private method to store data through kvc;

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

[0026] Specifically, the key operations in the step S5 include login and payment.

[0027] An iOS platform-based mobile token management system, comprising: a first login module, an identification and decoding module, a time verification module, a dynamic code generation and comparison module, and a secondary verification module.

[0028] The first login module is configured to enable mobile token verification after a user successfully logs in on an official website, and a server issues an encrypted string according to account information.

[0029] The identification and decoding module is configured to enable a user to scan and identify the encrypted string and decode it using an iOS mobile token manager to obtain a secret.

[0030] The time verification module is configured to send a verification time signal from the mobile token manager to compare the local time with the server time.

[0031] The dynamic code generation and comparison module is configured to generate a dynamic code using a SHA1 encryption algorithm according to the current time and a step length, save the secret to an iOS system CTKeyChain, and then compare the dynamic code with a server-side dynamic code; if the comparison is successful, the binding is successful.

[0032] The secondary verification module is configured to enable the mobile token to perform secondary verification when a user logs in next time and performs a key operation, and only if the verification is successful, the user can enter the system.

[0033] Specifically, the dynamic code generation and comparison module comprises a dynamic code generation unit and a dynamic code comparison unit.

[0034] The dynamic code generation unit is configured to generate a dynamic code using a SHA1 encryption algorithm according to the current time and a step length.

[0035] The dynamic code comparison unit is configured to save the secret to an iOS system CTKeyChain, and then compare the dynamic code with a server-side dynamic code; if the comparison is successful, the binding is successful.

[0036] An electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of an iOS platform-based mobile token management method when executing the computer program.

[0037] A computer readable storage medium, having stored thereon computer instructions, which when executed perform steps of a method for managing a mobile phone token based on an iOS platform.

[0038] Compared with the prior art, the present application has the following advantages:

[0039] 1. The present application proposes a mobile phone token management system based on an iOS platform, and optimizes and improves the architecture, operation steps and process, and the system has the advantages of simple process, low investment and operation cost, and low production cost.

[0040] 2. The present application proposes a method for managing a mobile phone token based on an iOS platform, and the mobile phone token authentication is an effective method to prevent attacks, and compared with the SMS verification code, the mobile phone token can save enterprise cost, and can be used permanently after being bound once, and has high stability, and the mobile phone token is based on a time-based one-time password algorithm, and does not need to request data, and is not affected by the current network, and all tokens in the device dynamic token manager can be scanned, and the tokens are automatically matched with accounts, and the tokens are automatically filled, and the operation is convenient.

[0041] 3. The present application proposes a method for managing a mobile phone token based on an iOS platform, which greatly reduces the artificial cost of API development, shortens the development time, and thus improves the software development efficiency. BRIEF DESCRIPTION OF DRAWINGS

[0042] Figure 1 A flowchart of the method for managing a mobile phone token based on an iOS platform of the present application;

[0043] Figure 2 A flowchart of a SMS secondary verification scheme of the method for managing a mobile phone token based on an iOS platform of the present application;

[0044] Figure 3 A flowchart of a mobile phone dynamic token scheme of the method for managing a mobile phone token based on an iOS platform of the present application;

[0045] Figure 4 An architecture diagram of the mobile phone token management system based on an iOS platform of the present application;

[0046] Figure 5 An electronic device diagram of the method for managing a mobile phone token based on an iOS platform of the present application. DETAILED DESCRIPTION

[0047] In order to make the technical means, creative features, purposes and effects of the present application easy to understand, in the description of the present application, it should be pointed out that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer" and the like indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the devices or elements referred to must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as limiting the present application. In addition, the terms "No. 1", "No. 2", "No. 3" are only for the purpose of description, and cannot be understood as indicating or implying relative importance. The present application will be further described below in conjunction with the specific embodiments.

[0048] Embodiment 1

[0049] Please refer to Figures 1-3 The present application provides an embodiment: a mobile phone token management method based on iOS platform, comprising the following specific steps:

[0050] Step S1: after the user successfully logs in to the official website, the mobile phone token verification is started, and the server issues an encrypted string according to the account information;

[0051] Step S2: the user scans and recognizes the encrypted string with the iOS mobile phone token manager and decodes it to obtain the secret;

[0052] Step S3: the mobile phone token manager sends a verification time signaling, compares the local time with the server time;

[0053] Step S4: according to the current time and the step, a dynamic code is obtained by using the SHA1 encryption algorithm, and the secret is saved to the iOS system CTKeyChain, then the user compares the dynamic code with the server dynamic code, and if the comparison is successful, the binding is successful;

[0054] Step S5: the next time the user logs in, the mobile phone token is required for secondary verification when performing key operations, and only after the verification is successful can the user enter the system.

[0055] The traditional scheme of secondary verification by mobile phone SMS verification code has several disadvantages: 1) the mobile phone SMS verification code has the risk of being maliciously taken; 2) the arrival rate of the mobile phone SMS verification code. At present, no SMS verification code platform can guarantee 100% arrival rate; 3) due to security vulnerabilities, the SMS may be intercepted by the network provider 4) with the increase of business, the SMS sending volume will greatly increase, increasing the enterprise SMS cost.

[0056] The step length in step S4 is 30s.

[0057] The specific method for obtaining the dynamic code in step S4 using the SHA1 encryption algorithm is as follows:

[0058] Step S401: The secret data is processed in blocks, and the block length is 512 bits.

[0059] Step S402: Two buffers are set, buffer 1 and buffer 2, wherein buffer 1 is marked as A, B, C, D, and E, and buffer 2 is marked as H0, H1, H2, H3, and H4.

[0060] The unit of the two buffers is a word, and the word is a 32-bit String, which can be represented as 8 hexadecimal sequences, for example: A103FE23.

[0061] Step S403: The buffer marked as H is filled.

[0062] The buffer marked as H is filled with the following values: H0: 0x67452301; H1: 0xEFCDAB89; H2: 0x98BADCFE; H3: 0x10325476; H4: 0xC3D2E1F0.

[0063] Step S404: For the block of secret data that does not meet the length and content, the padding method is used to supplement the data.

[0064] Step S405: Set A = H0, B = H1, C = H2, D = H3, and E = H4, update the values in buffer 2, and output H0', H1', H2', H3', and H4', wherein H0' = A + H0, H1' = B + H1, H2' = C + H2, H3' = D + H3, and H4' = E + H4.

[0065] The padding method in step S404 includes: first filling a bit of 1, then filling N bits of 0, and finally filling 64 bits of length information of the block length M, satisfying the constraint condition: (L M +1+N+64)%512=0, wherein L M represents the length of the block length M.

[0066] The specific implementation steps of CTKeyChain in step S4 are as follows:

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

[0068] Step S412: Declare data storage and extraction related methods through the category file NSObject+CTKeyChain, and define the data storage method +setDataWithKey:NSString*key and the data extraction method +NSString*dataWithKey:NSString*key in the implementation section;

[0069] Step S413: The category file NSObject+CTKeyChain obtains the Ivars value of the system keychain keyChain structure body through the runtime reflection mechanism, defines the value as key, then assigns a value to key, and then traverses all properties and methods of the structure body, obtains each value, and then calls the keyChain private method to store data through kvc;

[0070] Step S414: Store data through the declaration and definition of the data storage method +setDataWithKey:NSString*key.

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

[0072] Embodiment 2

[0073] Please refer to Figure 4 The application provides another embodiment: a mobile phone token management system based on an iOS platform, comprising: a first login module, an identification and decoding module, a time verification module, a dynamic code generation and comparison module, and a secondary verification module.

[0074] The first login module is used for starting mobile phone token verification after a user successfully logs in on an official website, and the server issues an encrypted string according to account information.

[0075] The identification and decoding module is used for a user to scan and identify the encrypted string and decode it using an iOS mobile phone token manager, and the secret is obtained through decoding.

[0076] The time verification module is used for the mobile phone token manager to send a verification time signaling, and compare the local time with the server time.

[0077] The dynamic code generation and comparison module is used for obtaining a dynamic code by using a SHA1 encryption algorithm according to the current time and the step length, saving the secret to the iOS system CTKeyChain, and then comparing the dynamic code with the server dynamic code, so that the user can bind successfully if the comparison is successful.

[0078] The secondary verification module is used for the user to log in next time, and the mobile phone token is used for secondary verification when the key operation is performed, so that the user can enter the system only if the verification is successful.

[0079] The dynamic code generation and comparison module comprises a dynamic code generation unit and a dynamic code comparison unit,

[0080] The dynamic code generation unit is configured to obtain a dynamic code by using an SHA1 encryption algorithm according to a current time and a step length.

[0081] The dynamic code comparison unit is configured to save the secret to an iOS terminal system CTKeyChain, and compare the dynamic code used by a user with a dynamic code on a server end, so that the binding is successful if the comparison is successful.

[0082] Embodiment 3

[0083] Please refer to Figure 5 An electronic device comprises a memory and a processor, the memory stores a computer program, and the processor implements the steps of the method for managing a mobile phone token based on an iOS platform when executing the computer program.

[0084] A computer readable storage medium stores computer instructions, and the computer instructions execute the steps of the method for managing a mobile phone token based on an iOS platform when running.

[0085] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can be in the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can be in the form of a computer program product implemented on one or more computer usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer usable program code.

[0086] The present application is described with reference to flowcharts and / or block diagrams of the method, device (system), and computer program product according to the embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of the flows and / or blocks in the flowcharts and / or block diagrams can be implemented by computer program instructions. These computer program instructions can be provided to a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to produce a machine, so that the instructions executed by the computer or other programmable data processing devices produce a device that implements the functions specified in the flowcharts and / or block diagrams. Figure 1 The device for implementing the functions specified in one flow or multiple flows and / or blocks Figure 1 The device for implementing the functions specified in one flow or multiple flows and / or blocks

[0087] These computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instructions which implement the Figure 1 function specified in the flow or flows and / or blocks Figure 1 of the block or blocks.

[0088] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions that are executed on the computer or other programmable apparatus provide steps for implementing the Figure 1 function specified in the flow or flows and / or blocks Figure 1 of the block or blocks.

[0089] The embodiments of the present application described above are merely intended to illustrate the present application, but not to limit the present application, and the above-mentioned specific embodiments are merely illustrative, but not restrictive, and any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application, and within the scope of the claims, should be included in the protection scope of the present application.

[0090] Finally: The above only describes the preferred embodiments of the present application, and is not intended to limit the present application, and any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application, and within the scope of the claims, should be included in the protection scope of the present application.

Claims

1. A mobile token management method based on the iOS platform, characterized in that, The specific steps include the following: Step S1: After successfully logging in on the official website, the user enables mobile token verification, and the server sends an encrypted string based on the account information; Step S2: The user scans the encrypted string with the iOS phone's token manager, decodes it, and obtains the secret. Step S3: The mobile token manager sends a time verification signal to compare the local time with the server time; Step S4: Based on the current time and step size, obtain the dynamic code using the SHA1 encryption algorithm, and save the secret to the iOS system CTKeyChain. Then, the user compares this dynamic code with the dynamic code on the server. If the comparison is successful, the binding is successful. Step S5: The next time a user logs in and performs a critical operation, a mobile token will be required for secondary verification. Only after successful verification can the user enter the system.

2. The mobile token management method based on the iOS platform as described in claim 1, characterized in that, The step size in step S4 is 30 seconds.

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

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

5. The mobile token management method based on the iOS platform as described in claim 4, characterized in that, The specific implementation steps of CTKeyChain in step S4 are as follows: Step S411: Create the Category file NSObject+CTKeyChain for the base class NSObject; Step S412: Declare data storage and retrieval related methods through the categorized file NSObject+CTKeyChain, and define the data storage method +setDataWithKey:NSString*key and the data retrieval method +NSString*dataWithKey:NSString*key in the implementation scope; Step S413: The categorized file NSObject+CTKeyChain obtains the Ivars value of the system keychain keyChain structure through runtime reflection mechanism, defines this value as key, assigns a value to key, then iterates through all properties and methods of the structure to obtain each value, and then KVC calls the private method of keyChain to store the data. Step S414: Data is stored by declaring and defining the data storage method +setDataWithKey:NSString*key.

6. The mobile token management method based on the iOS platform as described in claim 5, characterized in that, The key operations in step S5 include logging in and making a payment.

7. A mobile token management system based on the iOS platform, implemented based on any one of claims 1-6, characterized in that, include: 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 initial login module is used to enable mobile token verification after the user successfully logs in to the official website. The server sends an encrypted string based on the account information. The identification and decoding module is used by users to scan and identify encrypted strings using the iOS mobile phone token manager, and decode them to obtain the secret. The time verification module is used by the mobile token manager to send a time verification signal to compare the local time with the server time. The dynamic code generation and comparison module is used to obtain a dynamic code based on the current time and step size using the SHA1 encryption algorithm, and at the same time save the secret to the iOS system CTKeyChain. Then, the user compares this dynamic code with the dynamic code on the server side. If the comparison is successful, the binding is successful. The secondary verification module is used to require users to perform secondary verification with a mobile token when logging in for critical operations. Only after successful verification can users enter the system.

8. A mobile token management system based on the iOS platform as described 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 a dynamic code using the SHA1 encryption algorithm based on the current time and step size; The dynamic code comparison unit is used to save the secret to the iOS system CTKeyChain. The user compares this dynamic code with the dynamic code on the server side. 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, characterized in that, When the processor executes the computer program, it implements the steps of the mobile token management method based on the iOS platform according to any one of claims 1-6.

10. A computer-readable storage medium, characterized in that, It stores computer instructions, which, when executed, perform the steps of the mobile token management method based on the iOS platform according to any one of claims 1-6.

Images