Access method, device and equipment of internal system and storage medium
By generating and sending a token on the client side, parsing and generating a password on the server side, and parsing the password entered by the user on the client side, and matching it with the verification information, the risk of external personnel accessing the real password of the internal system is eliminated, and secure access to the internal system is achieved. It is suitable for various network environments.
Patent Information
- Application Number
- CN202211428977.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-11-15
- Publication Date
- 2025-12-05
- Estimated Expiration
- 2042-11-15
AI Technical Summary
When external personnel access internal enterprise systems, there is a risk of account password sharing and leakage when they come into contact with the real passwords of the internal systems, and the security needs to be improved.
The client generates a token and sends it to the server. The server parses the token to generate the first password. The client responds with the second password entered by the user and parses it. It then combines the second password with the stored token to generate verification information. The verification information is matched with the parsed verification fields to determine whether the second password is valid, thus preventing external personnel from accessing the real password of the internal system.
It improves the security of internal system access, is suitable for different intranet and extranet environments, prevents external personnel from accessing the real password of the internal system, and enhances data protection.
Smart Images

Figure CN115766222B_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of data processing technology, and in particular to an access method, apparatus, device, and storage medium for an internal system. Background Technology
[0002] Data breaches occur frequently, and more and more companies are beginning to prioritize data security. A company's internal systems contain critical data and are typically strictly restricted to internal employees. However, in certain special circumstances, such as system failures requiring third-party solutions, external access to internal systems may be necessary.
[0003] Typically, it is necessary to disclose the login accounts and passwords of internal systems to external personnel, which may lead to risks such as account and password sharing, local storage, and account and password leakage, and security needs to be improved. Summary of the Invention
[0004] In order to solve the above-mentioned technical problems, or at least partially solve the above-mentioned technical problems, this disclosure provides an access method, apparatus, device and storage medium for an internal system.
[0005] In a first aspect, embodiments of this disclosure provide a method for accessing an internal system, including:
[0006] The client generates a token and sends the token to the server; the token's fields include the password seed information, the current counter value, and the algorithm version number.
[0007] The server parses the token to generate a first password; wherein, when the algorithm version number is a first version number, the server generates the first password based on the parsed seed information and the current value of the counter; when the algorithm version number is a second version number, the server generates the first password based on the current server time and the seed information.
[0008] The client responds to receiving the second password input by the user by parsing the second password. When the first version number is parsed, the client generates verification information based on the stored seed information and the parsed count value. When the second version number is parsed, the client generates the verification information based on the stored seed information and the current local time.
[0009] The client matches the verification information with the parsed verification fields to determine whether the second password is valid.
[0010] Secondly, embodiments of this disclosure provide an access device for an internal system, comprising:
[0011] A sending module is used to generate a token and send the token to the server; wherein, the fields of the token include password seed information, current counter value, and algorithm version number;
[0012] A parsing module is used to parse the token to generate a first password; wherein, when the algorithm version number is a first version number, the server generates the first password based on the parsed seed information and the current value of the counter; when the algorithm version number is a second version number, the server generates the first password based on the current server time and the seed information.
[0013] A generation module is used to respond to receiving a second password input by a user and parse the second password. When the first version number is parsed, the client generates verification information based on stored seed information and parsed count value. When the second version number is parsed, the client generates the verification information based on stored seed information and current local time.
[0014] The verification module is used to match the verification information with the parsed verification fields to determine whether the second password is valid.
[0015] Thirdly, embodiments of this disclosure provide an electronic device, including: a processor; a memory for storing executable instructions of the processor; the processor being configured to read the executable instructions from the memory and execute the instructions to implement the internal system access method described in the first aspect above.
[0016] Fourthly, embodiments of this disclosure provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the access method for the internal system described in the first aspect.
[0017] Compared with the prior art, the technical solution provided in this disclosure has the following advantages: the client generates a token and sends the token to the server. The server parses the token to generate a first password. The client responds by receiving and parsing the second password input by the user, and generates verification information by combining it with the stored token. The verification information and the parsed verification fields are matched to determine whether the second password is valid. Thus, a password-based login method for internal systems is provided, which avoids external personnel from accessing the real password of the internal system, improves security, and is applicable to different intranet and extranet environments. Attached Figure Description
[0018] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.
[0019] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0020] Figure 1 A flowchart illustrating an internal system access method provided in an embodiment of this disclosure;
[0021] Figure 2 A schematic diagram illustrating another method for accessing an internal system provided in an embodiment of this disclosure;
[0022] Figure 3 A schematic diagram illustrating another method for accessing an internal system provided in an embodiment of this disclosure;
[0023] Figure 4 A schematic diagram illustrating another method for accessing an internal system provided in an embodiment of this disclosure;
[0024] Figure 5 This is a schematic diagram of the structure of an access device for an internal system provided in an embodiment of this disclosure. Detailed Implementation
[0025] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.
[0026] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.
[0027] Figure 1 This is a flowchart illustrating an internal system access method provided in an embodiment of the present disclosure. The method provided in this embodiment can be executed by an internal system access device, which can be implemented in software and / or hardware and can be integrated into any electronic device with computing capabilities.
[0028] like Figure 1 As shown, the method for accessing an internal system provided in this disclosure embodiment may include:
[0029] Step 101: The client generates a token and sends the token to the server.
[0030] The token's fields include the password's seed information, the current counter value, and the algorithm version number.
[0031] In this embodiment, for internal systems that require external personnel to log in, in order to prevent external personnel from accessing the real password, firstly, the client of the internal system generates a token, stores the token on the client, and sends the token to the server of the internal system.
[0032] As an example, a token consists of the following fields: user identifier, password seed information, current counter value, algorithm version number, signature, bounce link, effective time, expiration time, and permissions. In this example, the user identifier is used to distinguish different tokens and passwords; the password seed information is a random number, such as a random number generated using the SHA1PRNG pseudo-random number generation algorithm; the current counter value is the current value of the client-side counter when the token was generated; the algorithm version number includes the first version number and the second version number; the signature is used to prevent data tampering; the effective time (timestamp, seconds) is the time when the server verifies the token's effectiveness; the expiration time (timestamp, seconds) is the time when the server verifies the token's expiration; and permissions indicate the account's permission scope.
[0033] This implementation uses a client / server architecture. The client generates a token, and the server generates a password. The generation of the password depends on the seed information in the token.
[0034] In one embodiment of this disclosure, to further enhance security, the seed information is stored in an encrypted manner to prevent leakage during transmission. The seed information is used as the key to perform symmetric encryption on the data field of the token, and the public key is used to perform asymmetric encryption on the seed information to generate an encrypted token, which is then sent to the server.
[0035] The system employs a combination of public and private keys on the server and public key on the client. It utilizes the SM2 national standard asymmetric encryption algorithm and the AES (Advanced Encryption Standard) symmetric encryption algorithm. The client generates a random number as a seed, which also serves as the AES encryption key. This key is used to symmetrically encrypt the data portion of the token using AES, and then the public key is used to asymmetricly encrypt this key, resulting in the encrypted token. Upon receiving the token, the server decrypts it using its private key to extract the encryption key. This decryption key is then used as the AES key to retrieve the business data portion of the token. The data portion may include, for example, the user identifier and the current counter value. Therefore, compared to the less efficient and longer asymmetric encryption, this method significantly improves encryption and decryption efficiency.
[0036] Optionally, after generating the encrypted token, the encrypted token can be encoded using the protobuff format. In this example, by comparing formats such as JSON, plaintext, XML, and protobuff, using the protobuff format to encode the password token makes the transmitted content shorter and easier to transmit.
[0037] Step 102: The server parses the token to generate the first password.
[0038] Specifically, when the algorithm version number is the first version number, the server generates the first password based on the parsed seed information and the current value of the counter. When the algorithm version number is the second version number, the server generates the first password based on the current server time and the seed information. Optionally, the first password includes a parameter field and a verification field. Parameter C is generated based on the current counter value, and the verification field is generated based on the seed information and parameter C; alternatively, parameter C is generated based on the current server time, and the verification field is generated based on the seed information and parameter C. Parameter C occupies 4 bytes, and the verification field occupies 3 bytes.
[0039] In this embodiment, the token is used to store business information and seed information for the password. The server generates the password based on the information in the token. For example, refer to... Figure 2 The server obtains and parses the token information. If the algorithm version number is determined to be the first version, the server updates the corresponding counter value based on the token information and uses the current counter value to determine the password parameter fields. If the algorithm version number is determined to be the second version, the password parameter fields are determined based on the current server time. Then, based on the seed information and parameter fields, the corresponding algorithm is used to generate verification fields, thus obtaining the first password. Users can obtain the first password through the interface provided by the server.
[0040] Step 103: The client responds to receiving the second password input by the user and parses the second password.
[0041] Specifically, when the first version number is parsed, the client generates verification information based on the stored seed information and the parsed count value; when the second version number is parsed, the client generates the verification information based on the stored seed information and the current local time.
[0042] In this embodiment, after the user obtains the password from the interface provided by the server, they use this password as a second password to log in to the client of the internal system. The client parses the second password; for example, referring to... Figure 3The client obtains the second password and performs base64 decryption, resulting in a byte array. The algorithm version number is the first byte value. If it is the first version number, the sequence number is decrypted from the byte array and used as the parsing counter / parameter C. If this counter value is less than the client-side counter value, the second password is deemed invalid; otherwise, subsequent steps are performed. If it is the second version number, parameter C is generated based on the local time, for example, generating the same parameter C within a specified time period. Then, the client generates verification information based on parameter C and seed information, and matches the verification information with the verification field of the second password. If they match, the password is confirmed as valid, allowing login to the internal system. Additionally, if it is the first version number, the counter value is updated, for example, by modifying the counter value to the specified value or incrementing it by one. If they do not match, the password is deemed invalid, and login to the internal system is not permitted.
[0043] Step 104: The client matches the verification information with the parsed verification fields to determine whether the second password is valid.
[0044] In this embodiment, the client decrypts the verification field O and parameter C in the second password, and generates verification information locally using the seed information and parameter C. If they match, the password is confirmed to be valid, allowing login to the internal system, and is marked as used to prevent replay attacks. If they do not match, the password is confirmed to be invalid, and login to the internal system is not allowed.
[0045] Reference Figure 4 , Figure 4 The diagram illustrates the interaction of this method in a practical application scenario. The client includes a privately deployed service, while the server acts as a central control service for passwords, managing token information for multiple private clients and generating passwords for the corresponding private client services based on the token content. Users generate tokens on the client, then access the server's password management system to register the generated tokens. External personnel access the password portal system, authenticate, and obtain the user's password to log in to the privately deployed client. This effectively prevents external personnel from directly accessing the real password. Furthermore, the password expires after use, and users can invalidate the token at any time on the client, ensuring security.
[0046] Among them, the two methods corresponding to the first and second version numbers can be applied to different scenarios. For example, the access authentication can be performed according to whether the machine time of the client and the server is consistent, or whether it is a private deployment (the client has no external network). This makes it suitable for different intranet and extranet environments.
[0047] In practical applications, for counters, since the number of bytes occupied by the counter value is fixed and there is an auto-incrementing behavior, key overflow may occur.
[0048] In one embodiment of this disclosure, a counter negotiation mechanism is implemented, whereby the client carries the latest counter value on its side each time it generates a token. Specifically, in scenario one, if the client finds that it does not currently possess any valid token during token generation, it sets its client-side counter to zero. When the server parses the token and finds its counter value to be zero, it sets its server-side counter to zero. In scenario two, if a counter overflow is detected during token generation, the client-side counter is set to zero, and when the server parses the token and finds its counter value to be zero, it sets its server-side counter to zero. This implements a counter overflow and renegotiation mechanism, further adapting to both intranet and extranet environments.
[0049] According to the technical solution of this disclosure embodiment, a token is generated by the client and sent to the server. The server parses the token to generate a first password. The client responds by receiving and parsing the second password input by the user, and generates verification information by combining it with the stored token. The verification information and the parsed verification fields are matched to determine whether the second password is valid. Thus, a password-based login method for internal systems is provided, which avoids external personnel from accessing the real password of the internal system, improves security, and is applicable to different intranet and extranet environments.
[0050] Figure 5 This is a schematic diagram of the structure of an access device for an internal system provided in an embodiment of the present disclosure, as shown below. Figure 5 As shown, the access device of the internal system includes: a sending module 51, a parsing module 52, a generating module 53, and a verification module 54.
[0051] The sending module 51 is used to generate a token and send the token to the server; wherein the fields of the token include password seed information, current counter value, and algorithm version number;
[0052] Parsing module 52 is used to parse the token to generate a first password; wherein, when the algorithm version number is a first version number, the server generates the first password according to the parsed seed information and the current value of the counter; when the algorithm version number is a second version number, the server generates the first password according to the current server time and the seed information.
[0053] The generation module 53 is used to respond to receiving a second password input by the user and parse the second password. When the first version number is parsed, the client generates verification information based on the stored seed information and the parsed count value. When the second version number is parsed, the client generates the verification information based on the stored seed information and the current local time.
[0054] The verification module 54 is used to match the verification information with the parsed verification fields to determine whether the second password is valid.
[0055] In one embodiment of this disclosure, the sending module 51 is specifically used for:
[0056] The seed information is used as a key to symmetrically encrypt the data field in the token, and the seed information is used as a public key to asymmetricly encrypt the seed information to generate an encrypted token.
[0057] Send the encrypted token to the server.
[0058] In one embodiment of this disclosure, the apparatus further includes an encoding module for encoding the encrypted token using the protobuff format after the encrypted token is generated.
[0059] In one embodiment of this disclosure, the token consists of the following fields: user identifier, password seed information, current counter value, algorithm version number, signature, bounce link, effective time, expiration time, and permissions.
[0060] In one embodiment of this disclosure, the sending module 51 is specifically used for:
[0061] If the client does not currently have a valid token, then the counter on the client side is set to zero;
[0062] Specifically, when the counter in the token is currently zero, the server sets the counter on the server side to zero.
[0063] In one embodiment of this disclosure, the sending module 51 is specifically used for:
[0064] If the client experiences a counter overflow when generating the token, the client-side counter will be set to zero.
[0065] Specifically, when the counter in the token is currently zero, the server sets the counter on the server side to zero.
[0066] The internal system access device provided in this disclosure can execute any internal system access method provided in this disclosure, and has the corresponding functional modules and beneficial effects for executing the method. Content not described in detail in the device embodiments of this disclosure can be referred to the description in any method embodiment of this disclosure.
[0067] This disclosure also provides an electronic device including one or more processors and a memory. The processor may be a central processing unit (CPU) or other processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device to perform desired functions. The memory may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor may execute the program instructions to implement the methods of the embodiments of this disclosure above and / or other desired functions. Various contents such as input signals, signal components, and noise components may also be stored in the computer-readable storage medium.
[0068] In one example, the electronic device may also include input and output devices, which are interconnected via a bus system and / or other forms of connection. Furthermore, the input device may include, for example, a keyboard, a mouse, etc. The output device can output various information to the outside, including determined distance information, direction information, etc. The output device may include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc. In addition, depending on the specific application, the electronic device may include any other suitable components such as a bus, input / output interfaces, etc.
[0069] In addition to the methods and apparatus described above, embodiments of this disclosure may also be computer program products, which include computer program instructions that, when executed by a processor, cause the processor to perform any of the methods provided in the embodiments of this disclosure.
[0070] Computer program products can be written in any combination of one or more programming languages to perform the operations of embodiments of this disclosure. The programming languages include object-oriented programming languages such as Java and C++, as well as conventional procedural programming languages such as C or similar languages. The program code can be executed entirely on a user's computing device, partially on a user's computing device, as a standalone software package, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.
[0071] Furthermore, embodiments of this disclosure may also be computer-readable storage media storing computer program instructions that, when executed by a processor, cause the processor to perform any of the methods provided in the embodiments of this disclosure.
[0072] Computer-readable storage media may take the form of any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may, for example, include, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.
[0073] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0074] The above description is merely a specific embodiment of this disclosure, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. A method of accessing an internal system, characterized by, The method comprises: The client generates a token and sends the token to the server; wherein the fields of the token include seed information of a password, a current value of a counter, and an algorithm version number; The server parses the token to generate a first password; wherein when the algorithm version number is a first version number, the server generates the first password according to the parsed seed information and the current value of the counter, and when the algorithm version number is a second version number, the server generates the first password according to a current server time and the seed information; The client parses the second password in response to receiving the second password input by a user, wherein when the first version number is parsed, the client generates verification information based on stored seed information and a parsed counter value, and when the second version number is parsed, the client generates the verification information based on stored seed information and a current local time; The client matches the verification information and a parsed verification field to determine whether the second password is valid.
2. The method of claim 1, wherein, The sending of the token to the server comprises: The data field in the token is symmetrically encrypted by using the seed information as a key, and the seed information is asymmetrically encrypted by using a public key to generate an encrypted token; The encrypted token is sent to the server.
3. The method of claim 2, wherein, After the encrypted token is generated, the method further comprises: The encrypted token is encoded in a protobuff format.
4. The method of claim 1, wherein, The token is composed of the following fields: a user identifier, seed information of a password, a current value of a counter, an algorithm version number, a signature, a back link, a valid time, an invalid time, and an authority; wherein the user identifier is used to distinguish different tokens and passwords.
5. The method of claim 1, wherein, The client generating the token comprises: If there is no valid token currently existing on the client side, the counter on the client side is set to zero; The server sets the counter on the server side to zero when the current value of the counter in the token parsed by the server is zero.
6. The method of claim 1, wherein, The client generating the token comprises: If there is a counter overflow when the token is generated on the client side, the counter on the client side is set to zero; The server sets the counter on the server side to zero when the current value of the counter in the token parsed by the server is zero.
7. An access device for an internal system, characterized in that The method comprises: A sending module is configured to generate a token and send the token to a server; wherein the fields of the token include seed information of a password, a current value of a counter, and an algorithm version number; A parsing module is configured to parse the token to generate a first password; wherein when the algorithm version number is a first version number, the server generates the first password according to the parsed seed information and the current value of the counter, and when the algorithm version number is a second version number, the server generates the first password according to a current server time and the seed information; The generating module is configured to parse the second password input by the user in response to receiving the second password, wherein when the first version number is parsed, the client generates verification information based on the stored seed information and the parsed count value, and when the second version number is parsed, the client generates the verification information based on the stored seed information and the current local time; The verification module is configured to match the verification information and the parsed verification field to determine whether the second password is valid.
8. The apparatus of claim 7, wherein, The sending module is specifically configured to: perform symmetric encryption on a data field in the token by taking the seed information as a key, perform asymmetric encryption on the seed information by taking a public key, and generate an encrypted token; send the encrypted token to the server.
9. An electronic device, comprising: The system comprises: a processor; a memory for storing executable instructions of the processor; the processor is configured to read the executable instructions from the memory and execute the instructions to implement the access method of the internal system according to any one of claims 1-6.
10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, and the computer program is executed by the processor to implement the access method of the internal system according to any one of claims 1-6.
Citation Information
Patent Citations
Method and system for identity authentication based on dynamic password
CN101582763A
Configuration-based joint login method and device, and computer device
CN111193725A