Login behavior auditing method and device

Abstract

The invention discloses a login behavior auditing method and device. The method comprises the steps that a login credential sent by a target user is received, and the login credential at least comprises identity information of the target user; after the identity information of the target user passes verification, obtaining a recent historical login record of the target user, the login record at least comprising a historical identifier of the target user; obtaining a user identifier of a target user at the current moment and a custom field of the target user at the current moment; and when the user identifier at the current moment is not matched with the historical identifier of the target user or the custom field at the current moment does not pass verification, determining that the login behavior of the target user at the current moment is abnormal. The method provided by the invention at least solves the technical problem of relatively low abnormal login behavior recognition efficiency caused by adopting a manual mode to recognize the abnormal login behavior from the historical log in related technologies.

Description

Technical Field

[0001] This application relates to the field of security technology, and more specifically, to a method and apparatus for auditing login behavior. Background Technology

[0002] With the accelerated development of digital transformation, information system security issues are becoming increasingly prominent. Account theft and impersonation are frequent security incidents, causing significant economic losses and data breach risks to businesses and individuals. Traditional security auditing methods rely on post-event analysis of system logs, requiring auditors to manually sift through massive amounts of data to identify abnormal login behavior. This method is not only inefficient but also prone to false positives and false negatives, failing to meet the high real-time and accuracy requirements of modern information systems. While username-and-password login is widely used in current authentication mechanisms, it has shortcomings in identifying login risks, especially in high-concurrency and high-data-volume environments. Due to the static nature of login information, traditional methods struggle to effectively identify changes in login behavior, particularly when user login environment or device information changes abnormally. Systems often fail to respond immediately, allowing security vulnerabilities to remain undetected for extended periods. Furthermore, traditional auditing systems rely primarily on automatic log recording for abnormal login detection, lacking mechanisms for user participation and real-time feedback. This passive approach means that auditors may need a considerable amount of time to identify unusual login behavior from a large amount of historical logs when conducting risk assessments, thus delaying the response to security incidents and increasing potential security threats. Summary of the Invention

[0003] This application provides a method and apparatus for auditing login behavior, which at least solves the technical problem that the identification efficiency of abnormal login behavior is low due to the use of manual methods to identify abnormal login behavior from historical logs in related technologies.

[0004] According to one aspect of the embodiments of this application, a method for auditing login behavior is provided, comprising: receiving a login credential sent by a target user, wherein the login credential contains at least the target user's identity information; after the target user's identity information is verified, obtaining the target user's most recent historical login record, wherein the login record includes at least: the target user's historical identifier; obtaining the target user's current user identifier and the target user's current custom field; and determining that the target user's current login behavior is abnormal if the current user identifier does not match the target user's historical identifier or the current custom field fails verification.

[0005] Optionally, the verification step of the custom field at the current moment includes: obtaining the target user's historical custom field from the login record, wherein the historical custom field is the custom field of the target user's last login, and the custom field is used to represent login remarks information and description information of business operations performed during this login; if the custom field at the current moment is the same as the historical custom field, it is determined that the custom field at the current moment has failed verification.

[0006] Optionally, obtaining the target user's most recent historical login record includes: obtaining the target user's user identifier and the timestamp of the current moment; and determining the login record with the timestamp closest to the current moment among the identifiers with the same user identifier of the target user in the preset audit log library as the target user's most recent historical login record.

[0007] Optionally, the method further includes: if there is no historical login record of the target user in the preset audit log library, marking the login record of the target user at the current moment as the first login; if the identity information of the target user is verified, determining to display a first control, wherein, when the first control is triggered, the login record of the target user is sent to the preset audit log library.

[0008] Optionally, after determining that the target user's login behavior is abnormal at the current moment, the method includes: if the abnormal login behavior is due to a custom field failing verification at the current moment, outputting a prompt message, wherein the prompt message is used to instruct the user to modify the custom field at the current moment; if the abnormal login behavior is due to a mismatch between the user identifier at the current moment and the target user's historical identifier, determining to display a second control, wherein when the second control is triggered, outputting an exception report, wherein the exception report includes: the target user's current login record and the target user's most recent historical login record, wherein the login record includes: the target user's user identifier and the target user's custom field.

[0009] Optionally, after obtaining the exception report, the method further includes: converting the exception report into a target format to obtain a converted exception report, wherein the target format is: and sending the converted exception report to an exception handling terminal through a message queue.

[0010] Optionally, sending the transformed exception report to the exception handling terminal via a message queue includes: establishing a TLS connection between the server and the message queue and a TLS connection between the message queue and the exception handling terminal; transmitting the transformed exception report to the message queue via the TLS connection, wherein the message queue is used to transmit the transformed exception report to the exception handling terminal via the TLS connection.

[0011] According to another aspect of the embodiments of this application, a login behavior auditing device is also provided, comprising: a receiving module, configured to receive a login credential sent by a target user, wherein the login credential contains at least the target user's identity information; a first obtaining module, configured to obtain the target user's most recent historical login record after the target user's identity information is verified, wherein the login record includes at least the target user's historical identifier; a second obtaining module, configured to obtain the target user's current user identifier and the target user's current custom field; and a determining module, configured to determine that the target user's current login behavior is abnormal if the current user identifier does not match the target user's historical identifier or the current custom field fails verification.

[0012] According to another aspect of the embodiments of this application, a computer device is also provided, including: a memory and a processor, wherein the memory is used to store program instructions; and the processor, connected to the memory, is used to execute the above-described auditing method for login behavior.

[0013] According to another aspect of the embodiments of this application, a computer program product is also provided, including computer instructions that, when executed by a processor, implement the auditing method for the above-mentioned login behavior.

[0014] In this embodiment, a login credential sent by a target user is received, wherein the login credential contains at least the target user's identity information; after the target user's identity information is verified, the target user's most recent historical login record is obtained, wherein the login record includes at least the target user's historical identifier; the target user's current user identifier and the target user's current custom field are obtained; if the current user identifier does not match the target user's historical identifier or the current custom field fails verification, the target user's current login behavior is determined to be abnormal. By detecting the target user's current user identifier and custom field, the purpose of determining abnormal login behavior is achieved, thereby achieving the technical effect of quickly identifying abnormal login behavior, and thus solving the technical problem of low efficiency in identifying abnormal login behavior due to the use of manual methods to identify abnormal login behavior from historical logs in related technologies. Attached Figure Description

[0015] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0016] Figure 1 This is a hardware structure block diagram of a computer terminal for implementing an auditing method for login behavior according to an embodiment of this application;

[0017] Figure 2 This is a flowchart of an auditing method for login behavior according to an embodiment of this application;

[0018] Figure 3 This is a structural diagram of a login behavior auditing system according to an embodiment of this application;

[0019] Figure 4 This is a structural diagram of a login behavior auditing device according to an embodiment of this application. Detailed Implementation

[0020] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0021] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0022] The information collected in this application embodiment is information and data authorized by the user or fully authorized by all parties. The collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with the relevant laws, regulations and standards of the relevant regions, and necessary confidentiality measures have been taken. It does not violate public order and good morals, and provides corresponding operation entry points for users to choose to authorize or reject the automated decision results. If the user chooses to reject, the process will proceed to the expert decision-making process.

[0023] To address the problems existing in related technologies, embodiments of this application provide a method for auditing login behavior, which can be run on... Figure 1 The computer terminal shown is explained below.

[0024] The login behavior auditing method provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware block diagram of a computer terminal for implementing an auditing method for login behavior is shown. Figure 1 As shown, the computer terminal 10 may include one or more processors (shown as 102a, 102b, ..., 102n in the figure) (the processor may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission module 106 for communication functions connected via wired and / or wireless networks. In addition, it may also include: a display, a keyboard, a cursor control device, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, and a BUS bus. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0025] It should be noted that the aforementioned one or more processors and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10. As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0026] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the login behavior auditing method in this embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the aforementioned login behavior auditing method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0027] The transmission module 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission module 106 includes a network interface controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission module 106 may be a radio frequency (RF) module, used for wireless communication with the Internet.

[0028] The display can be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10.

[0029] It should be noted here that, in some optional embodiments, the above... Figure 1 The computer terminal shown may include hardware elements (including circuitry), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware and software elements. It should be noted that... Figure 1 This is only one instance of a specific particular instance, and is intended to illustrate the types of components that may exist in the aforementioned computer terminal.

[0030] In the above operating environment, this application provides an embodiment of a login behavior auditing method. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0031] Figure 2 This is a flowchart of an auditing method for login behavior according to an embodiment of this application, such as... Figure 2As shown, the method includes the following steps:

[0032] Step S202: Receive login credentials sent by the target user, wherein the login credentials contain at least the target user's identity information;

[0033] Step S204: After the target user's identity information is verified, obtain the target user's most recent historical login record, wherein the login record includes at least: the target user's historical identifier;

[0034] Step S206: Obtain the user identifier of the target user at the current time and the custom field of the target user at the current time;

[0035] Step S208: If the user identifier at the current moment does not match the historical identifier of the target user or the custom field at the current moment fails to pass verification, it is determined that the login behavior of the target user at the current moment is abnormal.

[0036] Through steps S202 to S208 above, the system receives login credentials sent by the target user, wherein the login credentials contain at least the target user's identity information; after the target user's identity information is verified, the system obtains the target user's most recent historical login records, wherein the login records include at least the target user's historical identifier; the system obtains the target user's current user identifier and the target user's current custom field; if the current user identifier does not match the target user's historical identifier or the current custom field fails verification, the system determines that the target user's current login behavior is abnormal. By detecting the target user's current user identifier and custom field, the system achieves the purpose of determining abnormal login behavior, thereby achieving the technical effect of quickly identifying abnormal login behavior and solving the technical problem of low efficiency in identifying abnormal login behavior due to the manual method used in related technologies to identify abnormal login behavior from historical logs. A detailed explanation follows.

[0037] In some embodiments of this application, the verification steps for the custom field at the current moment are as follows: obtain the target user's historical custom field from the login record, wherein the historical custom field is the custom field of the target user during the last login, and the custom field is used to represent login remarks information and description information of business operations performed during this login; if the custom field at the current moment is the same as the historical custom field, determine that the custom field at the current moment has failed verification.

[0038] It should be noted that the requirement for users to fill in custom fields in this embodiment is actually a requirement for users to actively report their login environment or purpose when logging in. This increases the user's participation in the security detection process, helps to build a more comprehensive user behavior profile, and improves the targeting of security strategies.

[0039] At the same time, setting different custom fields for the two sets can prevent the account's custom fields from being stolen and misused, thus increasing the accuracy of security verification.

[0040] Understandably, custom fields should at least include: login remarks and a description of the business operation. Alternatively, custom fields can also include: Login location description: A description of the login location entered by the user, such as "office," "home," or specific geographical location information. This helps the system identify whether the login behavior matches the user's usual login location. Device description: A description of the device used by the user during login, such as device type or device ID. This helps the system detect abnormal logins due to device changes. Login purpose: The purpose of the user's login or a brief description of the current business operation, such as "viewing a report" or "performing a transfer." This can be used for business scenario analysis during security audits to determine whether the login behavior conforms to normal operating patterns. Security question answers: If the system has security questions set up, the answers the user needs to fill in during login. This can serve as a secondary verification method to strengthen the identity confirmation process.

[0041] If the target user's login behavior is abnormal at the current moment because the custom field at that moment fails verification, a prompt message is output, instructing the user to modify the custom field at that moment. There are various methods for verifying custom fields, such as real-time front-end verification, hash comparison, or direct string comparison. If the custom field is repeated in two login attempts, submission is blocked and the message "Please change your custom description" is displayed. The specific steps are as follows: Taking hash comparison as an example, the front-end collects the custom field information filled in by the user on the user login page, such as the login location description; performs a hash operation on the user-submitted custom field to obtain a hash value. The back-end reads the hash value of the user's custom field from a preset audit log library during the most recent login. The hash value of the custom field in this login is compared with the hash value of the previous login. If the two hash values ​​are the same, it indicates that the custom field has not changed. If the hash values ​​are found to be the same, the front-end receives a message from the back-end prompting the user "The custom description must not be the same as last time, please change it." This step enables real-time feedback on the front-end, avoiding invalid login attempts. After a user modifies a custom field and resubmits it, the backend recalculates the new hash value and stores it in the audit log database along with the user's other login information for comparison during the next login. Taking direct string comparison as an example, the custom fields from the current login are directly compared with those from the previous login to check if they are exactly the same. If the field content is identical, the frontend will receive feedback from the backend, prompting the user to change the custom field. After the user modifies and resubmits, the new custom field content is recorded and stored in the audit log database, becoming the comparison benchmark for the next login.

[0042] In some embodiments of this application, the specific steps for obtaining the target user's most recent historical login record are as follows: Obtain the target user's user identifier and the timestamp of the current moment; under the same identifier as the target user in the preset audit log library, determine the login record with the timestamp closest to the current moment as the target user's most recent historical login record. If no historical login record of the target user exists in the preset audit log library, mark the target user's current login record as the first login; if the target user's identity information is verified, determine to display a first control ("Submit" button), wherein, when the first control is triggered, the target user's login record is sent to the preset audit log library. If the target user's current login behavior is abnormal because the current user identifier does not match the target user's historical identifier, determine to display a second control ("Report" button), wherein, when the second control is triggered, an exception report is output, wherein the exception report includes: the target user's current login record and the target user's most recent historical login record, wherein the login record includes: the target user's user identifier and the target user's custom fields.

[0043] In practical applications, a unified interface can display the previous and current login information, along with two custom fields. If the user identifier from the previous login record does not match the current login (i.e., it's not the account holder logging in), the page provides a "Report" button. If the user identifier from the previous login record matches and the custom fields meet expectations (but differ from the previous login record), the page provides a "Submit" button.

[0044] This application proposes a responsive layout for dual-column comparison display, real-time validation of multi-line text boxes, and red / green buttons at the bottom to distinguish between reporting and submit functions. For example, the webpage adopts a responsive layout design to ensure good display on different devices and screen sizes. The display interface uses a dual-column layout, with the left column displaying information related to the previous login and the right column for the user to enter detailed information for the current login. The specific display process is as follows: When a user accesses the login page, the system automatically queries the user's most recent login record in a preset audit log database, including login time, IP address, device information, and custom field content. The left column is filled with detailed information from the previous login record, while the right column displays a blank form for the user to fill in the corresponding information for the current login. The dual-column comparison layout intuitively shows the differences between the two login information, making it easier for users to understand and fill in. In the multi-line text boxes of the right form, the user fills in custom field information, such as a detailed description of the login location or a brief description of the business operation. While the user is entering custom fields, the front end detects changes in the text boxes, executes field validation logic in real time, and sends the currently entered custom fields to the back end, requesting an immediate comparison of the uniqueness of the fields. Upon receiving the request, the backend compares it with the custom fields in the history using either hash comparison or direct string comparison. If a duplicate field is detected, the backend immediately returns an error message. The frontend dynamically updates the page based on the results returned by the backend. If the custom field is different from the previous one, the text box remains in its normal state; if they are the same, a warning message, such as "Please change your custom description," is displayed below the text box.

[0045] The interaction process of the controls is as follows: When the page loads, by default, both the "Report" button (red) and the "Submit" button (green) are disabled. The "Submit" button becomes clickable after the user successfully modifies a custom field and passes validation (if it differs from the previous custom field). The "Report" button remains active under all circumstances, allowing the user to report any anomalies immediately.

[0046] Understandably, when all required fields are filled correctly and custom fields are unique, the user clicks the "green submit" button to complete login and information archiving. If the user finds abnormal login information, such as an IP address that does not belong to their frequently used network, they can choose to click the "red report" button. After clicking the "submit" button, the system records all information of this login to the preset audit log database, including timestamps, IP addresses, device information, and verified custom fields. This information will be used for routine checks. When the "report" button is clicked, the system generates an anomaly report, encapsulating all information from the previous and current logins together, and immediately notifies business personnel or the SOC through secure channels, triggering the anomaly handling process. When uploading the anomaly report, the system uses a message queue to deliver the anomaly report asynchronously, ensuring that reports are not lost in high-concurrency scenarios.

[0047] In another optional approach, the detection of custom fields also includes the following methods: whether the business operation described by the custom field belongs to the operation in the business operation manual, whether the login device is a device frequently used by the target user, and whether the login location is a location frequently used by the target user.

[0048] After the second control is triggered, the system encapsulates all the information from both logins (including custom fields) into an exception report and sends it asynchronously to the Security Operations Center (SOC), triggering the exception handling process.

[0049] After the first control is triggered, the system archives the login information to the preset audit log library for routine testing.

[0050] After receiving the anomaly report, the anomaly report is converted into a target format to obtain a converted anomaly report, wherein the target format is; the converted anomaly report is sent to the anomaly handling terminal (security operations center) through a message queue.

[0051] It should be noted that the target format is JSON.

[0052] In some embodiments of this application, the specific steps for sending the converted exception report to the exception handling terminal via a message queue are as follows: establishing a TLS connection between the server and the message queue and a TLS connection between the message queue and the exception handling terminal; transmitting the converted exception report to the message queue via the TLS connection, wherein the message queue is used to transmit the converted exception report to the exception handling terminal via the TLS connection.

[0053] To prevent tampering with log information in the pre-defined audit log database, this application embodiment also provides a log storage method, append-only mode, and digital signature, supporting a timestamp-based integrity verification mechanism, as follows: Step 1: Data Preparation and Append-On Collecting Login Information: After a user successfully logs in, the system collects all necessary login details, including time, IP address, device information, user-defined fields, etc. The collected login information is converted into JSON or other structured data formats for subsequent processing and storage. Instead of overwriting existing information, the new login record is appended to the end of the audit log database. During encryption, a 2048-bit RSA private key and public key are generated by the system security component. The private key is kept internally and strictly confidential, while the public key can be distributed to business personnel or the Security Operations Center (SOC) for signature verification. A hash algorithm is used to perform a hash operation on the structured login information to generate a fixed-length data digest. The data digest is signed using the system's internal RSA private key to generate a digital signature. This digital signature is the result of the encryption operation based on the private key. When storing login records, the generated digital signature is associated with the structured login information. The digital signature can be stored as part of the login record or in a separate signature record associated with it. Login records with digital signatures are appended to the audit log repository. Each write operation is ensured to be atomic, meaning either all writes succeed or no write occurs, avoiding data inconsistency. A precise timestamp indicating the record's creation time is appended with each new login record. The digital signature of each login record is decrypted using the RSA public key in the pre-defined audit log repository to obtain a data digest. The content of the login record is re-hashed to generate a new data digest. The old and new data digests are compared; if they do not match, the record may have been tampered with. In practical applications, the integrity of each record can be verified sequentially according to the timestamps.

[0054] Before an anomaly report transmission begins, the server and SOC exchange digital certificates via SSL / TLS to verify each other's identities and negotiate encryption algorithms and keys. When the user clicks the "Report" button, the front-end encrypts the anomaly report data using the negotiated encryption algorithm and key, ensuring the data is not decrypted during transmission. The encrypted data is sent via HTTPS (Hypertext Transfer Protocol Secure). Simultaneously, during anomaly report transmission, the server implements XSS and SQL filtering to prevent malicious data injection and attacks. Furthermore, when an anomaly report is sent from the server to the SOC, the SOC first uses the server's public key to verify the validity of the certificate sent by the server and whether it was issued by a trusted CA, thus confirming the server's identity. Upon receiving the anomaly report, the server also uses the SOC's public key to verify its certificate, ensuring the report's recipient is the intended SOC and not just any third party capable of eavesdropping on network requests. After both parties have successfully authenticated each other, data transmission is encrypted using the TLS protocol.

[0055] During encryption and decryption, the TLS handshake protocol is used to exchange keys and generate session keys, which are used to encrypt and decrypt the content of the exception report.

[0056] To better illustrate the login behavior auditing method proposed in this application, an login behavior auditing system is also proposed in the embodiments of this application, such as... Figure 3 As shown, it includes: Front-end UI: responsible for information display, field input, and button interaction. Application server: implements identity verification, historical record query, field uniqueness verification, exception detection, and report generation. Audit log library: uses a relational database to persist login logs. Report forwarding service: uses a message queue to achieve asynchronous and reliable exception report delivery.

[0057] The login behavior auditing method proposed in this application embodiment, through proactive reporting and differentiated judgment of custom fields, allows the system to identify anomalies during user login, eliminating the need for manual screening by business personnel afterward. Only truly abnormal login behaviors are pushed to business personnel, significantly reducing the amount of logs that need to be processed. Each login records the time, IP address, device fingerprint, and custom description, forming a traceable end-to-end audit. Custom fields can be freely defined according to business needs (such as "login location description," "business operation remarks," etc.), suitable for various scenarios. Digital signatures, TLS two-way authentication, and asynchronous message queue delivery ensure that reports are tamper-proof, transmission is secure, and the system is highly available.

[0058] It should be noted that the login behavior auditing method proposed in this application adopts an active reporting mechanism to proactively report login information to the SOC after a user successfully logs in, enabling real-time monitoring. User-defined fields (such as login remarks and business operation descriptions) are introduced, and it is mandatory that these fields differ from the previous ones. This field difference allows for rapid determination of whether a login is abnormal, improving the accuracy and sensitivity of anomaly detection. The system automatically compares the user identifier of the current login with the identifier of the previous login record; if they do not match, it is determined that the login is not by the user, and a "report" entry is directly provided, shortening the response time for business personnel to discover anomalies. Two login information entries are displayed on the same page, providing either a report (abnormal) or submit (normal) button, allowing users to immediately report anomalies after logging in, avoiding manual auditing afterwards. A message queue is used to achieve asynchronous and reliable delivery of anomaly reports, ensuring that reports are not lost in high-concurrency scenarios and can quickly reach the security operations center. All login records are stored using append-only writing and digital signature methods to ensure the integrity and immutability of audit data. Custom fields can be flexibly defined according to different industry needs (such as "Login Location Description" and "Business Operation Remarks"), making this method applicable to various scenarios. The entire front-end to back-end chain employs HTTPS, TLS mutual authentication, input filtering (to prevent XSS / SQL injection), and signature verification to ensure the security of information during transmission, storage, and processing.

[0059] Figure 4 An auditing device for login behavior is shown, the device comprising:

[0060] The receiving module 40 is used to receive a login credential sent by the target user, wherein the login credential contains at least the target user's identity information;

[0061] The first acquisition module 42 is used to acquire the most recent historical login record of the target user after the target user's identity information is verified, wherein the login record includes at least: the target user's historical identifier;

[0062] The second acquisition module 44 is used to acquire the user identifier of the target user at the current time and the custom field of the target user at the current time;

[0063] The determination module 46 is used to determine that the login behavior of the target user at the current moment is abnormal if the user identifier at the current moment does not match the historical identifier of the target user or the custom field at the current moment fails to pass the verification.

[0064] The aforementioned login behavior auditing device receives login credentials sent by a target user, wherein the login credentials contain at least the target user's identity information; after the target user's identity information is verified, it obtains the target user's most recent historical login records, wherein the login records include at least the target user's historical identifier; it obtains the target user's current user identifier and the target user's current custom field; if the current user identifier does not match the target user's historical identifier or the current custom field fails verification, it determines that the target user's current login behavior is abnormal. By detecting the target user's current user identifier and custom field, the device achieves the purpose of determining abnormal login behavior, thereby achieving the technical effect of quickly identifying abnormal login behavior and solving the technical problem of low efficiency in identifying abnormal login behavior due to the manual method used in related technologies to identify abnormal login behavior from historical logs.

[0065] The determination module 46 includes a verification submodule, used to verify the custom fields at the current moment. The verification steps for the custom fields at the current moment include: obtaining the target user's historical custom fields from the login record, wherein the historical custom fields are the custom fields used by the target user during the last login, and the custom fields are used to represent login remarks and descriptions of business operations performed during this login; if the custom fields at the current moment are the same as the historical custom fields, it is determined that the custom fields at the current moment have failed verification.

[0066] The first acquisition module 42 includes an acquisition submodule, used to acquire the most recent historical login record of the target user, including: acquiring the user identifier of the target user and the timestamp of the current moment; and determining the login record with the closest timestamp to the current moment under the same identifier as the user identifier of the target user in the preset audit log library as the most recent historical login record of the target user.

[0067] The acquisition submodule includes: a processing unit, used to mark the target user's current login record as the first login when there is no historical login record of the target user in the preset audit log library; and to determine to display a first control when the target user's identity information is verified, wherein when the first control is triggered, the target user's login record is sent to the preset audit log library.

[0068] The processing unit includes: a reporting subunit, configured to, after determining that the target user's current login behavior is abnormal, output a prompt message if the abnormality is due to a custom field failing verification, wherein the prompt message instructs the user to modify the custom field; and determine to display a second control if the abnormality is due to a mismatch between the user identifier and the target user's historical identifier, wherein, when the second control is triggered, an exception report is output, wherein the exception report includes: the target user's current login record and the target user's most recent historical login record, wherein the login record includes: the target user's user identifier and the target user's custom field.

[0069] The aforementioned login behavior auditing device further includes: a sending submodule, used to convert the abnormal report into a target format after receiving the abnormal report, to obtain a converted abnormal report, wherein the target format is; and to send the converted abnormal report to the abnormal processing terminal through a message queue.

[0070] The sending submodule includes a sending unit, used to send the transformed exception report to the exception handling terminal via a message queue, including: establishing a TLS connection between the server and the message queue and a TLS connection between the message queue and the exception handling terminal; transmitting the transformed exception report to the message queue via the TLS connection, wherein the message queue is used to transmit the transformed exception report to the exception handling terminal via the TLS connection.

[0071] It should be noted that, Figure 4 The login behavior auditing device shown is used to perform... Figure 2 The auditing method for login behavior shown above also applies to the auditing device for login behavior, and will not be repeated here.

[0072] This application also provides a computer device, including: a memory and a processor, wherein the memory is used to store program instructions; and the processor, connected to the memory, is used to execute the auditing method for the above-mentioned login behavior.

[0073] This application also provides a computer program product, including computer instructions that, when executed by a processor, implement the steps of the login behavior auditing method in this application.

[0074] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0075] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0076] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0077] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0078] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0079] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0080] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for auditing login behavior, characterized in that, include: Receive login credentials sent by the target user, wherein the login credentials contain at least the target user's identity information; After the target user's identity information is verified, the target user's most recent historical login record is obtained, wherein the login record includes at least: the target user's historical identifier; Obtain the target user's current user identifier and the target user's current custom fields; If the user identifier at the current moment does not match the target user's historical identifier or if the custom field at the current moment fails validation, the login behavior of the target user at the current moment is determined to be abnormal.

2. The method according to claim 1, characterized in that, The verification steps for the custom field at the current moment include: The historical custom fields of the target user are obtained from the login record. The historical custom fields are the custom fields of the target user during the last login. The custom fields are used to represent login remarks and descriptions of business operations performed during the current login. If the custom field at the current moment is the same as the historical custom field, it is determined that the custom field at the current moment has failed validation.

3. The method according to claim 1, characterized in that, Obtain the target user's most recent login history, including: Obtain the user identifier of the target user and the timestamp of the current moment; Under the same user identifier as the target user in the preset audit log library, the login record with the timestamp closest to the current moment is determined as the target user's most recent historical login record.

4. The method according to claim 3, characterized in that, The method further includes: If no historical login record of the target user exists in the preset audit log library, the current login record of the target user will be marked as the first login. If the target user's identity information is verified, a first control is displayed. If the first control is triggered, the target user's login record is sent to the preset audit log library.

5. The method according to claim 4, characterized in that, After determining that the target user's login behavior is abnormal at the current moment, the following steps are taken: If the login behavior of the target user at the current moment is abnormal because the custom field at the current moment fails to be verified, a prompt message is output, wherein the prompt message is used to instruct the user to modify the custom field at the current moment; If the login behavior of the target user at the current moment is abnormal because the user identifier at the current moment does not match the target user's historical identifier, a second control is determined to be displayed. When the second control is triggered, an exception report is output. The exception report includes the target user's current login record and the target user's most recent historical login record. The login record includes the target user's user identifier and the target user's custom fields.

6. The method according to claim 1, characterized in that, After receiving the anomaly report, the method further includes: The anomaly report is converted into a target format to obtain a converted anomaly report, wherein the target format is: The transformed exception report is sent to the exception handling terminal via a message queue.

7. The method according to claim 6, characterized in that, Sending the transformed exception report to the exception handling terminal via a message queue includes: Establish a TLS connection between the server and the message queue, and a TLS connection between the message queue and the exception handling terminal; The transformed exception report is transmitted to the message queue via the TLS connection, and the message queue is used to transmit the transformed exception report to the exception handling terminal via the TLS connection.

8. A device for auditing login behavior, characterized in that, include: A receiving module is used to receive login credentials sent by a target user, wherein the login credentials contain at least the target user's identity information; The first acquisition module is used to acquire the target user's most recent historical login record after the target user's identity information is verified, wherein the login record includes at least: the target user's historical identifier; The second acquisition module is used to acquire the user identifier of the target user at the current time and the custom field of the target user at the current time; The determination module is used to determine that the login behavior of the target user is abnormal at the current moment if the user identifier at the current moment does not match the historical identifier of the target user or the custom field at the current moment fails to pass the verification.

9. A computer device, characterized in that, include: A memory and a processor, wherein the memory is used to store program instructions; The processor, connected to the memory, is used to execute the login behavior auditing method according to any one of claims 1 to 7.

10. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the auditing method for login behavior as described in any one of claims 1 to 7.

Images