Campus network login security detection method

Abstract

The invention provides a campus network login security detection method, which comprises the following steps of: binding an account by using asymmetric encryption, acquiring user information, and keeping the user information consistent in a block chain and an external database through an intelligent contract; during login, login information is acquired, the login time is signed by using the private key, and exception processing is performed according to the login information; performing verification again according to the login IP, the equipment information and the geographic position, and performing abnormal response; analyzing behaviors of the user in the system by using a sliding window to perform early warning and response; and recording the login information of the abnormal user into a database. Through combination of multiple verification means such as asymmetric encryption, a block chain technology and behavior analysis, security threats such as hostile attacks and account embezzlement can be effectively prevented. Especially for situations such as abnormal login, equipment authorization abnormity, IP address change and the like, the system can timely discover and take corresponding measures, so that the overall security of the system is greatly improved.

Description

Technical Field

[0001] The present invention belongs to the technical field of network security, and in particular relates to a campus network login security detection method. Background Art

[0002] Currently, many universities still rely primarily on traditional account and password security for their campus networks. While firewalls, VPNs, and other encryption methods are employed to protect user data transmission, detection and prevention of abnormal login behavior remain inadequate. Traditional login authentication mechanisms struggle to effectively prevent attackers from stealing user passwords or using other methods to bypass authentication, thereby gaining access to the system and performing malicious operations, stealing sensitive information, or launching cyberattacks. Therefore, a more intelligent and flexible security solution is needed to address the ever-changing nature of cyberattacks. Summary of the Invention

[0003] In view of this, the present invention aims to overcome the shortcomings of the above-mentioned problems in the prior art and proposes a campus network login security detection method, which ensures account security through asymmetric encryption, builds a dynamic risk assessment model based on user behavior analysis, and combines device authorization, IP address monitoring, multiple verifications and other means to monitor abnormal login behavior in real time, thereby effectively improving the security of the campus network.

[0004] To achieve the above object, the technical solution of the present invention is achieved as follows:

[0005] A campus network login security detection method, comprising:

[0006] Step 1: Use asymmetric encryption to bind the account and obtain user information, and use smart contracts to keep the user information consistent in the blockchain and external database;

[0007] Step 2: Obtain login information during login and use the private key to sign the login time, and perform exception handling based on the login information;

[0008] Step 3: Verify again based on login IP, device information, and geographic location, and respond to exceptions;

[0009] Step 4: Use sliding windows to analyze user behavior in the system for early warning and response;

[0010] Step 5: Record the login information of abnormal users into the database.

[0011] Furthermore, the step 1 specifically includes:

[0012] When users bind their account and mobile phone number on the campus network, the system generates a pair of asymmetric encryption keys. The private key is used for digital signatures, and the public key is used for verification.

[0013] Record the user's public key and the hash value of the user's login information, attach a digital signature, set up a smart contract and regularly check with the school database;

[0014] The hash value on the blockchain and the user's personal information and public key information are recorded in the database.

[0015] Furthermore, the step 1 further includes:

[0016] If the blockchain operation is successful, its status is fed back to the system and the update in the database is confirmed;

[0017] If a blockchain operation fails, the database operation is rolled back to ensure consistency between the two.

[0018] Furthermore, the step 1 further includes:

[0019] Regularly scan the database and blockchain for data consistency checks. If there is any inconsistency, trigger an alert and perform repairs.

[0020] Furthermore, the step 1 further includes:

[0021] Set the trigger conditions of the smart contract. When the hash in the database and the blockchain is found to be inconsistent, the smart contract automatically triggers an event to notify or roll back the database data.

[0022] Furthermore, the step 2 specifically includes:

[0023] Identity verification request: When a user logs into the campus network, the system requires the user to provide account information and use a private key to sign a specific message. The signed message, along with the account information, is encrypted using symmetric encryption technology and sent to the authentication server.

[0024] Public key verification: After receiving the login request, the authentication server obtains the account and password from the school database. If the password is incorrect for more than five consecutive times, it will be locked for two hours. After the account and password match correctly, the public key corresponding to the account is obtained and the public key is used to decrypt and verify the signed message sent by the user. If the decryption is successful and the message content is consistent with the expectation, the user's identity is verified to be legitimate.

[0025] Furthermore, the step 3 specifically includes:

[0026] When the login IP address is not the school or home location, use SMS verification code for security verification;

[0027] When logging in to a new device, the account is authenticated using the SMS verification code sent to the original device.

[0028] When two devices log in at the same time, the login status is determined based on the IP and distance.

[0029] Furthermore, the step 4 specifically includes:

[0030] By collecting and analyzing users' daily behavior data on the campus network, a behavior baseline is established for each user;

[0031] After the user logs in, the behavioral data is continuously monitored. When the deviation between the monitored user behavior and the baseline is greater than the set range, the system conducts further checks and verifications;

[0032] If the system detects possible abnormal behavior, it triggers the multi-factor authentication mechanism and requires the user to authenticate through other means.

[0033] Furthermore, it also includes using a sliding time window to calculate the user's behavior baseline and dynamically updating the behavior baseline.

[0034] Furthermore, it also includes auditing the entire abnormal login event and recording the relevant behavior and login data in the database.

[0035] Compared with the existing technology, the campus network login security detection method described in the present invention has the following advantages:

[0036] This invention combines multiple verification methods, including asymmetric encryption, blockchain technology, and behavioral analysis, to effectively prevent security threats such as malicious attacks and account theft. In particular, the system can promptly detect and take appropriate measures for unusual logins, device authorization anomalies, and IP address changes, significantly improving the overall security of the system.

[0037] The present invention dynamically adjusts the behavioral baseline through a sliding time window and user behavior patterns. The system can effectively avoid misjudgments caused by seasonal changes and special circumstances (such as exam weeks, holidays, etc.).

[0038] This invention uses blockchain technology to record the hash value of public keys and login information, preventing data in the database from being modified and ensuring data consistency and integrity. This reduces unnecessary recovery and backup requirements caused by data tampering or loss, and reduces the consumption of data storage resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] The accompanying drawings, which constitute part of the present invention, are provided to provide a further understanding of the present invention. The exemplary embodiments of the present invention and their descriptions are provided to explain the present invention and do not constitute an undue limitation of the present invention. In the accompanying drawings:

[0040] Figure 1 Schematic diagram of the method of the present invention. DETAILED DESCRIPTION

[0041] It should be noted that, in the absence of conflict, the embodiments of the present invention and the features in the embodiments may be combined with each other.

[0042] In the description of the present invention, it should be understood that the terms "center", "longitudinal", "lateral", "up", "down", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inside", "outside" and the like indicate orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as limiting the present invention. In addition, the terms "first", "second", etc. are only used for descriptive purposes and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, features defined as "first", "second", etc. may explicitly or implicitly include one or more of the features. In the description of the present invention, unless otherwise specified, "multiple" means two or more.

[0043] In the description of the present invention, it should be noted that, unless otherwise expressly specified or limited, the terms "mounted," "connected," and "connected" should be understood in a broad sense. For example, they may refer to fixed connections, detachable connections, or integral connections; mechanical connections or electrical connections; direct connections or indirect connections through an intermediate medium; and internal communication between two components. Those skilled in the art will understand the specific meanings of the above terms in the present invention based on specific circumstances.

[0044] The present invention will be described in detail below with reference to the accompanying drawings and in conjunction with embodiments.

[0045] like Figure 1 As shown, the present invention provides a campus network login security detection method, comprising:

[0046] Step 1: Use asymmetric encryption to bind the account and obtain user information, and use smart contracts to keep the user information consistent in the blockchain and external database;

[0047] Step 2: Obtain login information during login and use the private key to sign the login time, and perform exception handling based on the login information;

[0048] Step 3: Verify again based on login IP, device information, and geographic location, and respond to exceptions;

[0049] Step 4: Use sliding windows to analyze user behavior in the system for early warning and response;

[0050] Step 5: Record the login information of abnormal users into the database.

[0051] In an embodiment of the present invention, in step 1, the account and personal login information are bound in the blockchain. When a student binds their account and mobile phone number on the campus network, the system generates a pair of asymmetric encryption keys, namely a public key and a private key. The private key is kept by the user, while the public key is uploaded to the campus network's authentication server. The private key is used to digitally sign the information uploaded by the user, and the public key is used for verification. The student's public key and the hash value of the user's login information are recorded and digitally signed. Key information such as student ID, home address, and primary login device information to determine whether the login is abnormal is recorded in the blockchain. A smart contract is set up and regularly checks with the school's Oracle database to prevent the initial information in the database from being modified. The hash value on the blockchain and the user's personal information (such as name, student ID, password, mobile phone number, email address, home address, login device information, and authorized devices, etc.) and public key information are recorded in the database. Because the authorized device ID and password may change, they are only recorded in the database.

[0052] In this embodiment of the present invention, a layered hybrid architecture is used to distribute smart contracts across different core blockchain nodes. By distributing smart contract tasks across different nodes, the burden on individual nodes can be reduced, achieving load balancing and efficient operation. Distributed execution enhances the decentralized nature of blockchain, avoiding single points of failure and centralized control issues.

[0053] Core nodes are run by three colleges with strong IT capabilities (e.g., the School of Computer Science, the School of Mathematics, and the School of Software) to ensure data integrity and security. Core nodes are responsible for processing block verification, consensus algorithm execution, block addition operations, and verification of external data within the blockchain network.

[0054] The School of Computer Science's core node is responsible for verifying newly submitted login information. It performs hash verification, encryption, and timestamp signature verification on user-uploaded data. Once verified, the results are sent to the School of Mathematics' node for storage and confirmation. In the blockchain network, the School of Computer Science's core node is responsible for executing consensus calculations and participating in the network's block verification and consensus processes.

[0055] The School of Mathematics core nodes are responsible for the storage and dissemination of the blockchain. All verified and agreed-upon block information is stored in a copy of the blockchain and participates in verifying whether the block complies with the PoS rules.

[0056] The Software Academy's core nodes are responsible for verifying the blockchain against external databases, performing data consistency checks by regularly scanning the database and blockchain. For example, a weekly verification mechanism calculates the hash value of the data in the database and compares it with the hash value recorded on the blockchain. If there is a discrepancy, an alert is triggered and manual remediation is performed.

[0057] In an embodiment of the present invention, consensus calculations calculate "equity" by determining the weight of computing power and storage capacity factors in the Proof of Stake (PoS) protocol at each node. The voting weight of a node is proportional to its "equity".

[0058] The School of Computer Science's core nodes possess significant computing resources, and their "equity" is correlated with their computing power. The School of Computer Science's nodes are capable of performing complex computations, such as hash calculations and digital signature verification. In the PoS mechanism, the School of Computer Science's nodes, for example, are assigned a higher weight based on their computing resources, giving them greater priority in validating new blocks.

[0059]

[0060] Among them: w1, w2, w3 are the weights of each factor, C f is the CPU clock frequency, I p is the number of instructions per second, B m is the memory bandwidth, L is the delay factor, D is the load factor, α1 and α2 are nonlinear weights used to adjust the contribution of each composite indicator to the computing power. The parameters are set according to the actual hardware facilities.

[0061] Normalize each indicator so that each indicator can be compared on a unified scale. For example, normalize each indicator to a range of 0 to 1. After normalization, weighted sum is performed. Assume that the maximum value of each indicator X is X max , then the normalized value is:

[0062]

[0063] The weights w1 and w2 reflect the importance of each indicator, while the geometric mean ensures that indicators of different magnitudes do not disproportionately affect the final result. The weight settings are shown in Table 1.

[0064] Table 1

[0065] <![CDATA[w1]]> <![CDATA[w2]]> School of Computer Science 0.7 0.3 School of Mathematics 0.3 0.7 School of Software 0.5 0.5

[0066] Normalize "equity" and the maximum value is X max , then the normalized value is:

[0067]

[0068] The calculation is based on the "equity" vote. The larger the equity, the greater the voting influence, with 1 for approval and 0 for opposition. The voting values of the three core nodes are calculated, and when the value exceeds the set consensus threshold of 0.51, the block is added to the blockchain.

[0069] The present invention also uses other colleges as light nodes, operating through the simplified payment verification (SPV) mechanism. Light nodes do not store the complete data of the entire blockchain, but only store the necessary block header information. Light nodes use the Merkle tree root in the block header (i.e., the root node of the login information hash) to verify whether the information exists in a certain block. By calculating the path of the information in the Merkle tree and comparing it with the Merkle tree root provided by the block header, light nodes can determine whether the information is authentic without downloading and verifying all transaction data in the block. These nodes only verify and confirm the validity of transactions by accessing the public chain data of the core node, thereby saving storage and computing resources.

[0070] In an embodiment of the present invention, if the blockchain operation succeeds, its status is fed back to the system and the update in the database is confirmed. If the blockchain operation fails, the database operation is rolled back to ensure consistency between the two and avoid data desynchronization or inconsistency.

[0071] In an embodiment of the present invention, an exception handling mechanism is also provided to set the triggering conditions of the smart contract. When the hashes in the database and the blockchain are found to be inconsistent, the smart contract automatically triggers an event to notify or roll back the database data.

[0072] 1. Automatic alerts and logging

[0073] Trigger an alarm: When the system detects that the hash value on the blockchain does not match the hash value in the database, it should first trigger an alarm to notify the system administrator or relevant responsible person for timely manual intervention.

[0074] Logging: At the same time, all relevant information (such as hash value on the blockchain, hash value in the database, user information, operation time, operation ID, etc.) is recorded in the system log to facilitate subsequent investigation and tracking.

[0075] 2. Rollback operation and data recovery

[0076] Rollback database operations: When the hash values do not match, roll back the operations in the database, undoing all related updates and avoiding storing incorrect data permanently in the database.

[0077] Recalculate hash value: The system recalculates the hash value of the data in the database and compares it with the hash value on the blockchain. If the data in the database has been tampered with or is incomplete, the correct data record is regenerated.

[0078] In an embodiment of the present invention, in step 2, when a user attempts to log in to the campus network, the system requires the user to provide account information and sign a specific message (such as the current timestamp) using a private key. The signed message, along with the account information, is encrypted using symmetric encryption technology and sent to the authentication server.

[0079] After receiving the login request, the authentication server retrieves the account and password from the school database. If the password is incorrect for more than five consecutive times, the account will be locked for two hours. Once the account and password match, the server retrieves the corresponding public key and uses it to decrypt the signed message sent by the user. If the decryption is successful and the message content is consistent with the expected value (e.g., the timestamp is within a reasonable range of 2 minutes), the user's identity is initially verified to be legitimate.

[0080] During the authentication process, login event-related information (such as account number, login time, IP address, and login device information) can also be encrypted and recorded in the database. During each authentication, the authentication server can check whether there are any abnormalities in the account's recent login behavior. When an account logs in on a new device, it is necessary to use the original device to perform authorization verification via SMS verification code and choose whether to trust the device. If you choose to trust, it will be recorded in the database and no verification will be required for the next login. The specific verification process is as follows:

[0081] (1) When the login IP address is not the school or home address, a text message verification code is used for security verification. If there are multiple login requests from different locations within a short period of time, more than two but less than three, the system will issue an alarm and require the user to re-enter the account and password. If there are more than three, the user will be forced to log out, the account will be locked for two hours, and an alarm will be issued to the administrator. A text message notification of abnormal login will also be sent to the user's mobile phone. This is shown in Table 2.

[0082] Table 2

[0083]

[0084]

[0085] (2) When logging in on a new device, you need to use the original device to authenticate with a text message verification code and choose whether to trust the device. If you choose to trust, the authentication will be recorded in the database and no further authentication will be required for the next login. When an unauthorized device attempts to log in, the system will send a login text message to the user's phone as a reminder. The original device can authorize up to two devices.

[0086] The present invention allows the user to view the list of authorized devices in the system and provides an option to manually cancel the authorization.

[0087] The present invention also regularly clears out device authorization records that have not been used for a long time to release authorization quotas.

[0088] The present invention also sets the number of authorizations according to the device type (such as mobile phone, tablet, computer), and only allows two devices to log in at the same time.

[0089] When two devices log in simultaneously, the system determines the login status based on the IP address and distance between them, preventing misidentification caused by students logging in from two devices. If the system's location service is not enabled, the user is prompted to enable it. If the user refuses, the system forces the user to log out and prevents login. After enabling it, the system determines the distance between the two devices, as shown in Table 3.

[0090] Table 3

[0091]

[0092] In an embodiment of the present invention, in step 4, corresponding behavioral baselines are established for students and teachers. A behavioral baseline is established for each user by collecting and analyzing daily behavioral data on the campus network (e.g., number of websites visited, duration of online use, data traffic, login time, etc.). This data can be stored in an external database and regularly updated and analyzed.

[0093] After a user logs in, their behavior data is continuously monitored. If a user's behavior deviates significantly from the baseline, such as suddenly visiting a large number of unfamiliar, high-risk websites, the system will conduct further checks and verification.

[0094] If the system detects possible abnormal behavior, it will trigger the multi-factor authentication mechanism, requiring the user to authenticate through other methods, such as SMS verification code and facial recognition.

[0095] Perform long-term statistics on each user's data and calculate baseline indicators:

[0096] Mean (μ): The average value of various user behaviors, such as daily traffic average, number of normal websites visited daily, login duration, number of dangerous websites visited, and login time.

[0097] Standard deviation (σ): measures the fluctuation range of user behavior.

[0098] Use weighted scoring method to set the weight of each indicator (w i ), as shown in Table 4, calculate the overall risk value:

[0099]

[0100] Table 4

[0101] Behavior Weight Daily traffic average 0.2 Number of normal websites visited daily 0.15 Login duration 0.2 Number of visits to dangerous websites 0.3 Login time 0.15

[0102] The weights in Table 4 are initial weights. The subsequent weights will be determined based on the proportion of each abnormal row in the audit information to all behaviors.

[0103]

[0104] Scorei is determined by the degree of deviation of the behavior:

[0105]

[0106] Low risk (Risk<2): User behavior changes are within a reasonable range and no alert is required.

[0107] Medium risk (2≤Risk<3): The behavior is unusual but may be accidental. The user's external access rights and bandwidth are restricted, and the user needs to re-enter their account and password.

[0108] Medium-high risk (3≤Risk<4): Abnormal behavior, re-enter the password and perform face recognition.

[0109] High risk (Risk ≥ 4): There may be malicious behavior, which should trigger an alarm and lock the account.

[0110] In the embodiment of the present invention, a sliding time window is also used to calculate the user's behavior baseline instead of a long-term fixed value. The sliding window time is shown in Table 5.

[0111] Table 5

[0112]

[0113]

[0114] The present invention can dynamically adjust the baseline as user habits change, avoiding misjudgments caused by seasonal changes or special circumstances (such as exam weeks and holidays).

[0115] In an embodiment of the present invention, once an abnormal login is confirmed, the system blocks further operations for verification and sends an alert to the user. Simultaneously, the incident is reported to school administrators, who investigate the abnormal login incident and analyze its cause and impact.

[0116] After the user confirms the security of their account, the system can assist them in resetting their password, replacing their private key, and restoring normal account usage. Furthermore, the present invention audits the entire abnormal login event, recording the relevant behavior and login data in a database for subsequent tracing and analysis. Detected abnormal login behavior is recorded, including the IP address, device ID, type of alarm triggered, login time, login duration, traffic usage, and the number of normal and abnormal websites visited.

[0117] In this embodiment of the present invention, external databases are regularly backed up and maintained to ensure data integrity and availability. Furthermore, based on the number of users and data growth, database storage capacity is appropriately expanded and data on graduated students is deleted. The databases storing user behavior and auditing data only store the most recent year's worth of user behavior data to reduce unnecessary resource waste.

[0118] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A campus network login security detection method, characterized by: include: Step 1: Use asymmetric encryption to bind the account and obtain user information, and use smart contracts to keep the user information consistent in the blockchain and external database; Step 2: Obtain login information during login and use the private key to sign the login time, and perform exception handling based on the login information; Step 3: Verify again based on login IP, device information, and geographic location, and respond to exceptions; Step 4: Use sliding windows to analyze user behavior in the system for early warning and response; Step 5: Record the login information of abnormal users into the database.

2. A campus network login security detection method according to claim 1, characterized in that: The step 1 specifically includes: When users bind their account and mobile phone number on the campus network, the system generates a pair of asymmetric encryption keys. The private key is used for digital signatures, and the public key is used for verification. Record the user's public key and the hash value of the user's login information, attach a digital signature, set up a smart contract and regularly check with the school database; The hash value on the blockchain and the user's personal information and public key information are recorded in the database.

3. A campus network login security detection method according to claim 2, characterized in that: The step 1 further comprises: If the blockchain operation is successful, its status is fed back to the system and the update in the database is confirmed; If a blockchain operation fails, the database operation is rolled back to ensure consistency between the two.

4. A campus network login security detection method according to claim 2, characterized in that: The step 1 further comprises: Regularly scan the database and blockchain for data consistency checks. If there is any inconsistency, trigger an alert and perform repairs.

5. A campus network login security detection method according to claim 2, characterized in that: The step 1 further comprises: Set the trigger conditions of the smart contract. When the hash in the database and the blockchain is found to be inconsistent, the smart contract automatically triggers an event to notify or roll back the database data.

6. A campus network login security detection method according to claim 1, characterized in that: The step 2 specifically includes: Identity verification request: When a user logs into the campus network, the system requires the user to provide account information and use a private key to sign a specific message. The signed message, along with the account information, is encrypted using symmetric encryption technology and sent to the authentication server. Public key verification: After receiving the login request, the authentication server obtains the account and password from the school database. If the password is incorrect for more than five consecutive times, it will be locked for two hours. After the account and password match correctly, the public key corresponding to the account is obtained and the public key is used to decrypt and verify the signed message sent by the user. If the decryption is successful and the message content is consistent with the expectation, the user's identity is verified to be legitimate.

7. A campus network login security detection method according to claim 1, characterized in that: The step 3 specifically includes: When the login IP address is not the school or home location, use SMS verification code for security verification; When logging in to a new device, the account is authenticated using the SMS verification code sent to the original device. When two devices log in at the same time, the login status is determined based on the IP and distance.

8. A campus network login security detection method according to claim 1, characterized in that: The step 4 specifically includes: By collecting and analyzing users' daily behavior data on the campus network, a behavior baseline is established for each user; After the user logs in, the behavioral data is continuously monitored. When the deviation between the monitored user behavior and the baseline is greater than the set range, the system conducts further checks and verifications; If the system detects possible abnormal behavior, it triggers the multi-factor authentication mechanism and requires the user to authenticate through other means.

9. A campus network login security detection method according to claim 8, characterized in that: It also includes using a sliding time window to calculate the user's behavior baseline and dynamically updating the behavior baseline.

10. A campus network login security detection method according to claim 1, characterized in that: It also includes auditing the entire abnormal login event, and recording the relevant behavior and login data in the database.

Images