Dynamic login security control method and device

Abstract

The invention relates to the technical field of computer network security, and particularly provides a dynamic login security control method and device, which are based on a dual-system collaboration mechanism, and dual systems are deployed in an intranet and an internet; the internal network deployment uses an RSA public key to encrypt a current timestamp, generate a loginCode, generate a jump link / jump / {loginCode} based on environment configuration of internet deployment and return the jump link / jump / {loginCode} to a user, in internet deployment, the loginCode in a URL is analyzed, an RSA private key is used for decryption to obtain an original timestamp, whether a difference value between the timestamp and current time is within a preset threshold value or not is verified, and if the verification is passed, the user does not pass the verification. Rendering a user name password login page; and if not, returning to the 404 error page. Compared with the prior art, malicious scanning, replay attacks and brute force cracking can be effectively resisted, and operation and maintenance safety and operation convenience are both considered.

Description

Technical Field

[0001] The present invention relates to the technical field of computer network security, and in particular provides a dynamic login security control method and device. Background Art

[0002] In traditional Internet systems, operations and maintenance personnel usually authenticate through fixed login pages (such as / login). However, such pages directly exposed to the Internet pose high security risks. For example: (1) Malicious attack risks: Attackers may attempt to invade the system through brute force cracking, password collision, etc. (2) Path exposure risk: Fixed login paths are easily detected by scanning tools, increasing the possibility of the system being attacked by a targeted attack; (3) Insufficient single-point protection: It relies solely on username and password authentication and lacks a dynamic verification mechanism, making it difficult to defend against advanced persistent threats (APTs).

[0003] In existing technologies, some solutions use IP whitelists or VPNs to restrict access rights, but these solutions have the following drawbacks: (1) Limited operation and maintenance flexibility, unable to adapt to the operation and maintenance needs of multiple locations and multiple networks; (2) The whitelist maintenance cost is high and it is difficult to deal with intranet penetration attacks; (3) Static protection mechanisms cannot dynamically respond to time-sensitive security requirements.

[0004] Therefore, there is an urgent need for a login control method that combines dynamic encryption verification and path hiding to improve system security while ensuring operation and maintenance convenience. Summary of the Invention

[0005] The present invention aims to address the deficiencies of the above-mentioned prior art and provides a dynamic login security control method with strong practicality.

[0006] A further technical task of the present invention is to provide a dynamic login security control device that is rationally designed, safe and applicable.

[0007] The technical solution adopted by the present invention to solve its technical problem is: A dynamic login security control method based on a dual-system collaboration mechanism, wherein the dual systems are deployed on an intranet and on the Internet; The clock synchronization module in the intranet deployment maintains time synchronization with the Internet deployment. The dynamic credential generation module provides the / applyLoginCode interface to receive login requests from operation and maintenance personnel, encrypt the current timestamp using the RSA public key, generate the loginCode, and based on the environment configuration of the Internet deployment, generate a jump link / jump / {loginCode} and return it to the user.

[0008] In Internet deployment, the routing is dynamically modified, the static / login path in the Vue2 front-end routing is removed, and a new dynamic route / jump / :loginCode is added to receive encrypted login credentials. The credential verification module parses the loginCode in the URL, uses the RSA private key to decrypt it to obtain the original timestamp, and verifies whether the difference between the timestamp and the current time is within the preset threshold. If the verification passes, the username and password login page is rendered; if it fails, a 404 error page is returned.

[0009] Furthermore, the RSA key management includes key generation and storage, key lifecycle management, and access control and auditing; In the key generation and storage described above, 2048 bits and the RSA algorithm are used to generate public and private key pairs. The key length supports dynamic upgrades. The private key deployed on the Internet is stored in the encryption hardware module or key management service. Plain text persistent storage is prohibited. Private key calls must pass dual authentication and are only accessible to the decryption module deployed on the Internet. The public keys deployed on the intranet are preset through a secure channel and rotated regularly.

[0010] Furthermore, in the key lifecycle management, when the public key is rotated, a new key pair is generated in the intranet step, and the old public key is retained until all associated loginCodes expire. The rotation of the private key requires the Internet deployment to be shut down for maintenance; If the private key is leaked, the Internet deployment will immediately activate the backup key pair and discard the original private key. At the same time, the intranet deployment will synchronously update the public key.

[0011] Furthermore, in the access control and audit, private key operation logs are recorded in real time, including decryption time, request IP and decryption results, and synchronized to the security audit platform. In the intranet deployment, a rate limit is set for the public key call interface.

[0012] Furthermore, Internet deployment and intranet deployment are synchronized with the same authoritative time server through the NTP protocol. If the intranet deployment cannot connect to the time server, the loginCode will be refused to be generated and an alarm will be issued; if the Internet deployment synchronization fails, decryption will still be performed using the local clock, and the decryption time is set to 1-3 minutes.

[0013] Furthermore, in the timestamp processing, the timestamp accuracy is at the second level. When generated in the intranet deployment, it is automatically rounded to the whole second. A clock drift of ±5 seconds between the decrypted timestamp and the current time of the internet deployment is allowed. The actual valid window is [T-5 seconds, T+55 seconds], and the total duration is still limited to 1 minute. The Internet deployment checks the clock deviation from the intranet deployment every minute. If a deviation of more than 1 second is detected three times in a row, a high-risk alarm is triggered and login verification is suspended. Operations and maintenance personnel manually calibrate the clock through the management interface deployed on the intranet, or switch to a backup time server.

[0014] Furthermore, the dynamic routing is security-enhanced. The / jump / :loginCode routing deployed on the Internet is set with an access frequency limit. If the limit is exceeded, the IP address is temporarily blocked. When the front-end page renders the login form, a one-time CSRF token is injected to prevent cross-site forgery requests.

[0015] Furthermore, the intranet deployment records the loginCode generation log, the Internet deployment records the decryption verification log, the log files are encrypted and stored, the retention period is ≥180 days, and the generation link is supported by reverse querying the loginCode.

[0016] A dynamic login security control device comprises: at least one memory and at least one processor; The at least one memory is configured to store a machine-readable program; The at least one processor is configured to call the machine-readable program to execute a dynamic login security control method.

[0017] Compared with the prior art, the dynamic login security control method and device of the present invention have the following outstanding beneficial effects: (1) Anti-malicious scanning and brute force cracking: By removing static login paths (such as / login) from Internet systems, the risk of attackers locating login entrances through path scanning is completely eliminated. The dynamically generated loginCode is unique and time-limited (e.g., valid for 1 minute). Even if it is intercepted, it cannot be reused, effectively preventing replay attacks.

[0018] (2) Strengthening security boundaries: In intranet deployment, it is only deployed on the intranet, and the / applyLoginCode interface is not exposed to the Internet, isolating the key encryption logic from a physical level; RSA public and private keys are stored separately to avoid system-wide security crashes caused by key leaks.

[0019] (3) Legitimate operation and maintenance personnel can quickly generate dynamic links through intranet deployment without the need for additional hardware or complex operations, balancing security and efficiency; The timestamp verification mechanism allows multiple attempts within a short time window to avoid false interception due to clock errors.

[0020] (4) System compatibility and scalability: It supports seamless integration with existing SpringBoot and Vue2 systems with low transformation costs; parameters such as time difference threshold and key length can be dynamically configured to meet the needs of different security level scenarios.

[0021] (5) Enhanced attack tracing capabilities: Automatically log failed decryption requests for illegal loginCodes to provide data support for subsequent security analysis; Combined with the timestamp, the attack time window can be accurately located to assist in tracing the source and collecting evidence. DETAILED DESCRIPTION

[0022] In order to enable those skilled in the art to better understand the solutions of the present invention, the present invention will be further described in detail below in conjunction with specific embodiments. Obviously, the embodiments described are only some embodiments of the present invention, rather than all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0023] A best embodiment is given below: A dynamic login security control method in this embodiment is based on a dual-system collaboration mechanism, wherein the dual systems include intranet deployment and Internet deployment; The clock synchronization module in the intranet deployment maintains time synchronization with the Internet deployment, with the error controlled to the millisecond level; The dynamic credential generation module provides the / applyLoginCode interface to receive login requests from operation and maintenance personnel. It uses the RSA public key in RSA key management to encrypt the current timestamp (format: yyyyMMddHHmmss) to generate the loginCode. Based on the environment configuration of the Internet deployment, it generates a jump link / jump / {loginCode} and returns it to the user.

[0024] In Internet deployment, the routing is dynamically modified. The static / login path in the Vue2 front-end routing is removed, and a dynamic route / jump / :loginCode is added to receive encrypted login credentials. The credential verification module parses the loginCode in the URL, decrypts it using the RSA private key to obtain the original timestamp, and verifies whether the difference between the timestamp and the current time is within the preset threshold (for example, 1 minute). If the verification passes, the username and password login page is rendered; if it fails, a 404 error page is returned.

[0025] The RSA key management policy includes: (1) Key generation and storage; Use 2048-bit RSA algorithm to generate public and private key pairs, and the key length can be dynamically upgraded (such as switching to 3072 bits to meet future security needs); The private key deployed on the Internet is stored in a cryptographic hardware module (HSM) or key management service (KMS). Plain text persistent storage is prohibited. Private key calls must pass two-factor authentication (such as API token + IP whitelist) and are only accessible to the decryption module of System B. The public key deployed on the intranet is pre-set through a secure channel (such as intranet HTTPS) and rotated regularly (for example, updated every 90 days).

[0026] (2) Key lifecycle management; When the public key is rotated, the intranet deployment generates a new key pair, and the old public key is retained until all associated loginCodes expire (for example, after 1 minute); Private key rotation requires Internet deployment downtime maintenance to ensure a seamless transition between old and new keys; If the private key is leaked, the Internet deployment will immediately activate the backup key pair and discard the original private key. At the same time, the intranet deployment will synchronously update the public key.

[0027] (3) Access control and auditing; Private key operation logs are recorded in real time, including decryption time, request IP, and decryption results, and synchronized to the security audit platform; Set a rate limit (such as 10 times per minute) for the public key call interface deployed on the intranet to prevent malicious batch generation of loginCode.

[0028] Internet deployment and intranet deployment are synchronized with the same authoritative time server (such as the National Time Service Center) through the NTP protocol to ensure that the clock error is ≤ 50 milliseconds.

[0029] If the intranet deployment cannot connect to the time server, the loginCode will be rejected and an alarm will be issued. If synchronization fails in the Internet deployment, decryption will still be performed using the local clock, and the decryption time is set to 2 minutes (manual confirmation by operation and maintenance is required).

[0030] The timestamp processing logic is: The timestamp precision is in seconds (format yyyyMMddHHmmss), and is automatically rounded to the whole second when generated for intranet deployment; The decrypted timestamp is allowed to have a clock drift of ±5 seconds compared to the current time of the Internet deployment; The actual effective window is [T-5 seconds, T+55 seconds], and the total duration is still limited to 1 minute.

[0031] The Internet deployment checks the clock deviation from the intranet deployment every minute. If a deviation of more than 1 second is detected three times in a row, a high-risk alarm is triggered and login verification is suspended. Operations and maintenance personnel can manually calibrate the clock through the management interface deployed on the intranet, or switch to a backup time server.

[0032] For dynamic routing security reinforcement: Set a frequency limit on the / jump / :loginCode route deployed on the Internet (e.g., 3 times per minute). If the limit is exceeded, the IP address will be temporarily blocked. When the front-end page renders the login form, a one-time CSRF token is injected to prevent cross-site forgery requests.

[0033] Intranet deployments record loginCode generation logs (including timestamp and generator IP address), while internet deployments record decryption verification logs (including decryption results and requesting IP address). Log files are encrypted and stored with a retention period of ≥180 days. Reverse query of the generation link using the loginCode is supported.

[0034] Supports the coexistence of multiple RSA key pairs, and uses the loginCode version number to identify the encryption algorithm (for example, v1 represents RSA-2048, and v2 represents RSA-3072). The time difference threshold can be dynamically configured through environment variables deployed over the Internet (for example, LOGIN_CODE_TTL=60), without the need to redeploy code.

[0035] Based on the above method, a dynamic login security control device in this embodiment includes: at least one memory and at least one processor; The at least one memory is configured to store a machine-readable program; The at least one processor is configured to call the machine-readable program to execute a dynamic login security control method.

[0036] The above-mentioned specific implementation methods are only specific cases of the present invention. The patent protection scope of the present invention includes but is not limited to the above-mentioned specific implementation methods. Any technical solutions that conform to the above-mentioned specific implementation methods of the present invention and any appropriate changes or substitutions made thereto by ordinary technicians in the relevant technical field shall fall within the patent protection scope of the present invention.

[0037] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to these embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the appended claims and their equivalents.

Claims

1. A dynamic login security control method, characterized in that: Based on the dual-system collaboration mechanism, the dual systems are deployed on the intranet and the Internet; The clock synchronization module in the intranet deployment maintains time synchronization with the internet deployment. The dynamic credential generation module provides the / applyLoginCode interface to receive login requests from operators, encrypt the current timestamp using the public key in the RSA key management, generate the loginCode, and then, based on the environment configuration of the internet deployment, generate a jump link / jump / {loginCode} and return it to the user. In Internet deployment, the routing is dynamically modified. The static / login path in the Vue2 front-end routing is removed, and a dynamic route / jump / :loginCode is added to receive encrypted login credentials. The credential verification module parses the loginCode in the URL, decrypts it using the RSA private key to obtain the original timestamp, and verifies whether the difference between the timestamp and the current time is within the preset threshold. If the verification passes, the username and password login page is rendered. If failed, a 404 error page is returned.

2. A dynamic login security control method according to claim 1, characterized in that: The RSA key management includes key generation and storage, key lifecycle management, access control and auditing; In the key generation and storage described above, 2048 bits and the RSA algorithm are used to generate public and private key pairs. The key length supports dynamic upgrades. The private key deployed on the Internet is stored in the encryption hardware module or key management service. Plain text persistent storage is prohibited. Private key calls must pass dual authentication and are only accessible to the decryption module deployed on the Internet. The public keys deployed on the intranet are preset through a secure channel and rotated regularly.

3. A dynamic login security control method according to claim 2, characterized in that: In the key lifecycle management, when the public key is rotated, a new key pair is generated in the intranet step, and the old public key is retained until all associated loginCodes expire. The rotation of the private key requires the Internet deployment to be shut down for maintenance; If the private key is leaked, the Internet deployment will immediately activate the backup key pair and discard the original private key. At the same time, the intranet deployment will synchronously update the public key.

4. A dynamic login security control method according to claim 3, characterized in that: In the access control and audit, private key operation logs are recorded in real time, including decryption time, request IP and decryption results, and synchronized to the security audit platform. In the intranet deployment, rate limits are set for the public key call interface.

5. A dynamic login security control method according to claim 4, characterized in that: Internet deployment and intranet deployment are synchronized with the same authoritative time server through the NTP protocol. If the intranet deployment cannot connect to the time server, the loginCode will be rejected and an alarm will be issued. If Internet deployment synchronization fails, decryption will still be performed using the local clock, and the decryption time is set to 1-3 minutes.

6. A dynamic login security control method according to claim 5, characterized in that: The timestamp accuracy is in seconds. When generated for intranet deployment, the timestamp is automatically rounded to the whole second. A clock drift of ±5 seconds between the decrypted timestamp and the current time for internet deployment is allowed. The actual valid window is [T-5 seconds, T+55 seconds], and the total duration is still limited to 1 minute. The Internet deployment checks the clock deviation from the intranet deployment every minute. If a deviation of more than 1 second is detected three times in a row, a high-risk alarm is triggered and login verification is suspended. Operations and maintenance personnel manually calibrate the clock through the management interface deployed on the intranet, or switch to a backup time server.

7. A dynamic login security control method according to claim 6, characterized in that: In the dynamic routing security reinforcement, the / jump / :loginCode route deployed on the Internet is set with an access frequency limit. If the limit is exceeded, the IP address is temporarily blocked. When the front-end page renders the login form, a one-time CSRF token is injected to prevent cross-site forgery requests.

8. A dynamic login security control method according to claim 7, characterized in that: The intranet deployment records the loginCode generation log, and the Internet deployment records the decryption verification log. The log files are encrypted and stored with a retention period of ≥180 days, and support the generation of links through reverse query of the loginCode.

9. A dynamic login security control device, characterized in that: include: at least one memory and at least one processor; The at least one memory is configured to store a machine-readable program; The at least one processor is configured to call the machine-readable program to execute the method according to any one of claims 1 to 8.