Account security login method, device and electronic equipment

Abstract

The application provides a safe login method and device of an account and electronic equipment, can backtrack the login information of the account which has performed login risk identification and successfully logged in during the login process, decouples the login risk identification and the login process, and realizes efficient post-login risk control. The safe login method of the account comprises: obtaining historical data backtracking parameters, the historical data backtracking parameters at least comprising information of a target login log, the target login log comprising login information of the account which has performed login risk identification and successfully logged in during the login process within a target time length; reading part or all line files of the target login log from a log storage device according to the historical data backtracking parameters, and parsing each line log information read into a message to obtain a message set; inputting the messages in the message set into a risk identification device, and obtaining a login risk identification result of the target login log output by the risk identification device.

Description

Technical Field

[0001] This application relates to the field of network security technology, and more specifically, to a secure login method, apparatus, and electronic device for an account. Background Technology

[0002] With the development of internet technology, more and more users are participating in online activities, most of which require login. Currently, login risk is primarily assessed through real-time risk control, with blocking and notifications as the main management methods, significantly impacting system performance and user experience. Embedding a real-time risk control service into the login process allows the service to calculate and store risk indicators using current login transaction data, simultaneously assessing the risk and returning the result. The account login system then implements corresponding strategies based on this result, such as allowing, blocking, or issuing notifications. However, the integration of the real-time risk control service into the login process means that slow processing or even serious malfunctions directly affect the core functionality of the account login system and negatively impact its processing efficiency. Therefore, how to better identify login risks to achieve secure account login is a pressing issue that needs to be addressed. Summary of the Invention

[0003] This application provides a secure login method, apparatus, electronic device, chip, and computer-readable storage medium for accounts. It can retrospectively analyze the login information of accounts that have successfully logged in and undergone login risk identification during the login process, enabling login risk identification based on historical login information. This achieves more secure account login, decouples login risk identification from the login process, and realizes efficient post-login risk control. It helps promote refined division of labor in login risk control, reduces the pressure of real-time login risk monitoring, and improves the efficiency of the identity authentication system. It can be combined with real-time login risk control to achieve comprehensive and accurate login risk control.

[0004] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0005] According to one aspect of this application, a secure login method for an account is provided, comprising:

[0006] Obtain historical data backtracking parameters, which include at least the information of the target login log, which includes the login information of accounts that have successfully logged in and whose login risk identification has been performed during the login process within the target time period;

[0007] Based on the historical data backtracking parameters, some or all lines of the target login log are read from the log storage device, and each line of log information is parsed into a message to obtain a message set;

[0008] Input the messages in the message set into the risk identification device, and obtain the login risk identification result of the target login log output by the risk identification device.

[0009] According to one aspect of this application, a secure account login device is provided, comprising:

[0010] The acquisition module is used to acquire historical data backtracking parameters. These historical data backtracking parameters include at least the information of the target login log, which includes login information within a target duration.

[0011] The processing model is used to read part or all of the line files of the target login log from the log storage device based on the historical data backtracking parameters, and parse each line of log information read into a message to obtain a message set;

[0012] The input module is used to input the messages in this message set into the risk identification device;

[0013] The acquisition module is also used to acquire the login risk identification result of the target login log output by the risk identification device.

[0014] According to one aspect of this application, an electronic device is provided, comprising: a processor and a memory for storing a computer program, the processor for calling and running the computer program stored in the memory to perform the steps of the secure login method for the aforementioned account.

[0015] According to one aspect of this application, a chip is provided, comprising: a processor for calling and running a computer program from a memory, causing the processor to perform the steps of the secure login method for the aforementioned account.

[0016] According to one aspect of this application, a computer-readable storage medium is provided for storing a computer program that causes a computer to perform the steps of the secure login method for the aforementioned account.

[0017] Based on the above technical solution, for the target login log, which includes login information of accounts that have successfully logged in and undergone login risk identification during the login process within the target time period, partial or complete line files of the target login log are read from the log storage device according to historical data backtracking parameters. Each line of log information is parsed into a message, which is then input into the risk identification device to obtain the login risk identification result of the target login log output by the risk identification device. This allows for backtracking of the login information of accounts that have successfully logged in and undergone login risk identification during the login process, achieving login risk identification based on historical login information backtracking. This results in more secure account login, decoupling login risk identification from the login process, achieving efficient post-event login risk control, promoting refined division of labor in login risk control, reducing the pressure of real-time login risk monitoring, improving the efficiency of the identity authentication system, and achieving comprehensive and accurate login risk control when combined with real-time login risk control.

[0018] Other features and advantages of the embodiments of this application will become apparent from the following detailed description, or may be learned in part by practice of this application.

[0019] It should be understood that the above general description and the following detailed description are merely exemplary and do not constitute a limitation on this application. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0021] Figure 1 The diagram illustrates a real-time login risk control method.

[0022] Figure 2 The diagram illustrates a near real-time login risk control approach.

[0023] Figure 3 This illustration schematically shows an application architecture diagram of a secure account login method provided in one embodiment of this application;

[0024] Figure 4 This illustration schematically shows an application architecture diagram of a secure account login method provided in another embodiment of this application;

[0025] Figure 5 A flowchart illustrating a secure account login method according to an embodiment of this application is shown schematically.

[0026] Figure 6 An application flowchart according to an embodiment of this application is shown;

[0027] Figure 7 A system workflow diagram according to an embodiment of this application is shown;

[0028] Figure 8 This illustration schematically shows a flowchart of a backtracking task according to an embodiment of the present application;

[0029] Figure 9 A flowchart of a backtracking task according to an embodiment of this application is shown;

[0030] Figure 10 A block diagram illustrating a secure account login device according to an embodiment of this application is shown schematically.

[0031] Figure 11 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0032] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided to make the description of this application more complete and to fully convey the concept of the exemplary embodiments to those skilled in the art. The accompanying drawings are schematic illustrations of this application and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted.

[0033] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more exemplary embodiments. Numerous specific details are provided in the following description to give a full understanding of exemplary embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced with one or more specific details omitted, or other methods, components, steps, etc., can be employed. In other instances, well-known structures, methods, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0034] Some of the block diagrams shown in the accompanying drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different networks, processor devices, or microcontroller devices.

[0035] With the research and advancement of artificial intelligence (AI) technology, AI is being researched and applied in various fields, such as smart homes, smart wearable devices, virtual assistants, smart speakers, smart marketing, autonomous driving, drones, robots, smart healthcare, and smart customer service. It is believed that with further technological development, AI will be applied in even more fields and play an increasingly important role. This application enables multi-speaker scene recognition and multi-speaker scene recognition network training based on AI technology.

[0036] Artificial intelligence (AI) is the theory, methods, technology, and application systems that use digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to achieve optimal results. In other words, AI is a comprehensive technology within computer science that attempts to understand the essence of intelligence and produce a new kind of intelligent machine that can react in a way similar to human intelligence. AI studies the design principles and implementation methods of various intelligent machines, enabling them to possess perception, reasoning, and decision-making capabilities—that is, to have learning abilities.

[0037] Machine learning (ML) is a multidisciplinary field involving probability theory, statistics, approximation theory, convex analysis, and algorithm complexity theory, among others. It specifically studies how computers can simulate or implement human learning behavior to acquire new knowledge or skills and reorganize existing knowledge structures to continuously improve their performance. Machine learning is the core of artificial intelligence and the fundamental way to endow computers with intelligence; its applications span all areas of artificial intelligence. Machine learning and deep learning typically include techniques such as artificial neural networks (e.g., convolutional neural networks), belief networks, reinforcement learning, transfer learning, inductive learning, and instructional learning.

[0038] Artificial intelligence combined with cloud services can also create AI cloud services, commonly known as AI as a Service (AIaaS). This is currently a mainstream service model for AI platforms. Specifically, AIaaS platforms break down several common AI services and provide them as independent or packaged services in the cloud. This service model is similar to opening an AI-themed marketplace: all developers can access and use one or more AI services provided by the platform through Application Programming Interfaces (APIs). Some experienced developers can also use the AI ​​frameworks and infrastructure provided by the platform to deploy and maintain their own dedicated cloud AI services.

[0039] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include an underlying platform, a platform product service layer, and an application service layer.

[0040] The underlying blockchain platform can include processing modules such as user management, basic services, smart contracts, and operational monitoring. The user management module is responsible for managing the identity information of all blockchain participants, including maintaining public and private key generation (account management), key management, and maintaining the correspondence between user real identities and blockchain addresses (access management). Furthermore, under authorization, it monitors and audits transactions of certain real identities and provides risk control rule configuration (risk control audit). The basic services module is deployed on all blockchain node devices to verify the validity of business requests. After consensus is reached on valid requests, they are recorded in storage. For a new business request, the basic services first perform interface adaptation parsing and authentication (interface adaptation), and then encrypt the business information through a consensus algorithm (consensus management). After encryption, the data is transmitted completely and consistently to the shared ledger (network communication) and recorded and stored. The smart contract module is responsible for contract registration, issuance, triggering, and execution. Developers can define contract logic using a programming language and publish it to the blockchain (contract registration). According to the contract terms, the key or other events are invoked to trigger execution and complete the contract logic. It also provides functions for contract upgrades and cancellations. The operation monitoring module is mainly responsible for deployment, configuration modification, contract settings, cloud adaptation, and real-time status visualization output during product release, such as alarms, monitoring network conditions, and monitoring the health status of node devices.

[0041] The platform's product service layer provides the basic capabilities and implementation frameworks for typical applications. Developers can leverage these basic capabilities, along with the specific characteristics of their business needs, to implement blockchain-based business logic. The application service layer provides blockchain-based application services to business stakeholders.

[0042] The secure login method or apparatus for accounts disclosed in this application may include a blockchain composed of multiple servers, where the servers are nodes on the blockchain.

[0043] To facilitate a better understanding of the embodiments of this application, the relevant terms are explained.

[0044] Identity and Access Management (IAM) systems feature single sign-on, robust authentication management, policy-based centralized authorization and auditing, dynamic authorization, and enterprise manageability.

[0045] The Unified Identity Authentication Cloud Platform (IDaaS) is a centralized identity management service based on cloud computing and a microservice architecture. Building upon the traditional 4A (Account, Authentication, Authorization, Audit) framework, it adds our unique application portal to form a 5A integrated platform. It provides enterprise users with a unified portal centered around a unified identity account, and developers can rapidly develop and integrate applications based on this platform. The 5A capabilities are: Unified Identity Account, Unified Identity Authentication, Centralized Authorization, Application Management, and Global Transparent Auditing.

[0046] Extract-Transform-Load (ETL) describes the process of extracting, transforming, and loading data from a source to a destination.

[0047] To facilitate a better understanding of the embodiments of this application, the real-time login risk control related to this application is explained. Specifically, as follows... Figure 1 As shown, the IAM system embeds a step of calling the real-time risk control service in the login process. The real-time risk control service uses the current login transaction data to calculate and store risk control indicators, and at the same time performs risk judgment on the current login transaction data and returns the risk judgment result. The IAM system implements corresponding strategies based on the result, such as allowing, blocking, and prompting.

[0048] In such Figure 1 In the IAM system shown, the risk control service is a critical node in the login process, requiring high efficiency, performance, and high availability. Slow processing or even serious failures directly impact the core functionality of the IAM system. The risk control service includes both indicator calculation and risk assessment, both of which require access to a risk indicator database. Under high-concurrency login scenarios, the risk control service faces significant system pressure.

[0049] To facilitate a better understanding of the embodiments of this application, the risk control of near real-time login related to this application is explained. Specifically, as follows... Figure 2As shown, in the login process, the IAM system sends the current login transaction data to the message middleware. The consumer node consumes the login transaction data in the message queue. After a certain amount of ETL, it sends it to the risk control service for risk indicator accumulation and risk assessment. The risky transaction data is then stored in the database or other storage methods for subsequent analysis.

[0050] In such Figure 2 The IAM system shown relies heavily on the robustness of the message middleware in its architecture and lacks historical log backtracking capabilities. This means that when risk control rules change, it's difficult to reassess the risk of historical login logs. This solution is essentially a post-event risk assessment method, but it requires embedding a message push mechanism into the real-time login process, which impacts the IAM system's processing efficiency.

[0051] The above Figure 1 and Figure 2 The problems with the IAM system shown are as follows:

[0052] (1) The real-time segmentation of login behavior risk rules is not clear enough.

[0053] Industry login behavior risks are primarily assessed in real-time, with blocking and notifications as the main control methods, which significantly impact system performance and user experience. Therefore, real-time segmentation of login risk behaviors should be implemented, and risk control rules based on T-1 day, T-1 hour, frequently used devices, and daily working hours should be categorized as post-event control rules, such as "The current login Internet Protocol (IP) has not been used in the past week."

[0054] (2) The login process is highly coupled with risk control services.

[0055] Post-event risk control solutions using message middleware still need to be embedded in the login process, which makes them highly dependent on message middleware and is not conducive to system decoupling.

[0056] (3) It is difficult to have a flexible and efficient solution for tracing back historical login behavior.

[0057] Currently, historical backtracking mostly requires searching for data in the historical database and then using additional technical solutions to replay the process. This is not convenient for production environments and also makes it difficult for business users to check the effectiveness of risk control rules in advance after making changes.

[0058] Based on the above problems, this application proposes a secure account login scheme, which is an efficient post-login risk control scheme. It helps to improve the refinement of risk control rules, facilitates the diversion of real-time, near-real-time, and post-login behavior risk control, and reduces the pressure of real-time monitoring.

[0059] Specifically, based on historical data backtracking parameters, partial or complete lines of the target login log are read from the log storage device. Each line of log information is parsed into a message, which is then input into the risk identification device to obtain the login risk identification result of the target login log. This allows for backtracking of login information for accounts that have successfully logged in and undergone login risk identification during the login process. This enables login risk identification based on historical login information backtracking, resulting in more secure account logins. By decoupling login risk identification from the login process, efficient post-event login risk control is achieved. This facilitates a more refined division of labor in login risk control, reduces the pressure on real-time login risk monitoring, and improves the efficiency of the identity authentication system. It can be combined with real-time login risk control to achieve comprehensive and accurate login risk control.

[0060] This application is applied to login risk control scenarios of identity authentication devices such as IAM / IDaaS, mainly targeting login risk indicators related to "time period", including risk control indicators such as "cumulative number of times", "cumulative duration" and "whether it has occurred before". Specific risk rules include "whether the number of failed login attempts is greater than 5 times in 1 hour", "whether the number of login attempts from the same IP address is greater than 10 times in 30 minutes", and "whether the account has been locked within a day".

[0061] Figure 3 This is an application architecture diagram of a secure account login method provided in one embodiment. For user login scenarios, it records and batch-tracks user historical login logs to identify login risk events, decoupling the identity authentication process from login risk assessment. This provides a highly efficient login behavior risk assessment method, in addition to real-time risk control, for high-concurrency IAM systems, especially cloud-deployed IDaaS systems. Figure 3 As shown, the application architecture includes an identity authentication device 110, a local disk 120, a log collection agent device 130, a log storage device 140, a risk control operation scheduling system 150, and a risk identification device 160. The risk identification device 160 may include a risk control service 161, a risk indicator calculation service 162, a risk judgment service 163, a risk indicator library 164, and a risk event library 165.

[0062] Specifically, in such Figure 3In the application architecture diagram of the secure login method shown, the identity authentication device 110 writes login logs and stores them on the local disk 120. The log collection agent device 130 collects historical login log files from the local disk 120 by querying the directory of the local disk 120 and stores the collected historical login log files on the log storage device 140. The risk control operation scheduling system 150 reads the target login log from the log storage device 140, processes the target login log to obtain the corresponding message set, and inputs the message set into the risk identification device 160 for login risk identification based on the target login log. The risk identification device 160 can provide risk control services. Specifically, the risk identification device 160 can accumulate risk indicators and make risk judgments, and store the risky login logs in a database or other storage methods for subsequent analysis.

[0063] Figure 4 The following is an application architecture diagram of a secure account login method provided in another embodiment. For user login scenarios, it records and batch-tracks user historical login logs to identify login risk events, decoupling the identity authentication process from login risk assessment. This provides a highly efficient login behavior risk assessment method, in addition to real-time risk control, for high-concurrency IAM systems, especially cloud-deployed IDaaS systems. Figure 4 As shown, the application architecture includes an identity authentication device 110, a local disk 120, a log collection agent device 130, a log storage device 140, a risk control job scheduling system 150, and a risk identification device 160. The risk control job scheduling system 150 includes job execution agent devices 151, 152, and 153. The risk identification device 160 may include a risk control service 161, a risk indicator calculation service 162, a risk judgment service 163, a risk indicator library 164, and a risk event library 165.

[0064] It should be noted that, in Figure 4 The example shown is of a risk control operation scheduling system 150 with three distributed operation execution agent devices. In practical applications, the number of operation execution agent devices can be flexibly set according to needs to improve the overall throughput.

[0065] Specifically, in such Figure 4In the application architecture diagram of the secure login method shown, the identity authentication device 110 writes login logs and stores them on the local disk 120. The log collection agent device 130 collects historical login log files from the local disk 120 by querying the directory of the local disk 120 and stores the collected historical login log files on the log storage device 140. The risk control operation scheduling system 150 reads the target login log from the log storage device 140 and performs operation resource allocation and unified scheduling for each operation execution agent device. Each operation execution agent device reads different login logs and, through processing the login logs, obtains the message set corresponding to the login logs. The messages in the message set are then pushed to the risk identification device 160 for login risk identification based on the target login logs. The risk identification device 160 can provide risk control services. Specifically, the risk identification device 160 can accumulate risk indicators and make risk judgments, and store the risky login logs in a database or other storage methods for subsequent analysis.

[0066] That is, in such Figure 4 The application architecture diagram of the secure login method shown allows for setting the number of concurrent backtracking tasks based on the number of job execution agent devices, and creating a corresponding number of backtracking tasks. In each backtracking task, a set of messages corresponding to a login log is obtained, and this set is input into the risk identification device 160. The device also retrieves the login risk identification result output by the risk identification device 160 for each backtracking task's login log. This improves the overall throughput.

[0067] In some implementations, the aforementioned identity authentication device 110 may be an IAM system, an IDaaS system, or other identity authentication systems; this application does not limit this.

[0068] The secure login solution for accounts described in this application does not involve embedded modifications to identity authentication devices (such as IAM systems or IDaaS systems).

[0069] In some implementations, the log collection agent device 130 and the IAM system 110 are deployed on the same node to collect log files from the authentication device 110 node and transmit them to the log storage device 140. Commonly used file collection agents such as Flume and Logstash, or even File Transfer Protocol (FTP) tools, can be used. Flume is a highly available, highly reliable, distributed system for massive log collection, aggregation, and transmission. Flume supports customizing various data senders in the log system for data collection; it also provides the ability to perform simple data processing and write to various customizable data receivers. Logstash, acting as a bridge between data sources and data storage and analysis tools, can accept almost any type of data, including logs, network requests, relational databases, sensors, and IoT data. FTP is a file transfer standard developed to enable file transfer over the internet, defining how files are transferred on the internet. In other words, through the FTP protocol, one can upload or download files to an FTP server on the internet.

[0070] In some implementations, the aforementioned log storage device 140 can be deployed independently or mounted on a local disk or Network Attached Storage (NAS) device to store and manage log files collected from various authentication device nodes 110. It should have the capability to configure historical log file cleanup policies and schedule cleanup scripts to run.

[0071] In some implementations, the aforementioned risk control operation scheduling system 150 is deployed on the same server node as the log storage device 140, and is used to manage, start, stop, and repeatedly execute specified risk control tasks. The risk control task reads login logs for a specified time period and sends them one by one to the risk identification device 160.

[0072] It should be noted that the aforementioned risk control service 161 may refer to a risk control service node or module, the aforementioned risk indicator calculation service 162 may refer to a risk indicator calculation service node or module, and the aforementioned risk judgment service 163 may refer to a risk judgment service node or module.

[0073] In some implementations, the aforementioned risk identification device 160 can be deployed separately as a risk control service node specifically for batch backtracking solutions, depending on the traffic volume.

[0074] In some implementations, the risk identification device 160 may not include the risk event database 165. In this case, it is not necessary to store the risky login records in a database or other storage method for subsequent analysis.

[0075] It is understood that the above application scenario is only an example and does not constitute a limitation on the secure login method for accounts provided in the embodiments of this application.

[0076] The servers involved in the above application architecture can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms. This application does not limit this.

[0077] The specific implementation process of the embodiments of this application will be described in detail below.

[0078] Figure 5 A schematic flowchart of a secure account login method 200 according to an embodiment of this application is shown. This secure account login method 200 can be executed by a device with computing power, such as the aforementioned risk control operation scheduling system 150. (Refer to...) Figure 5 As shown, the secure login method 200 for this account can include at least S210 to S230, detailed below:

[0079] In S210, historical data backtracking parameters are obtained. These historical data backtracking parameters include at least the information of the target login log, which includes the login information of accounts that have successfully logged in and whose login risk identification has been performed during the login process within the target time period.

[0080] In some embodiments, historical data backtracking parameters can be obtained from a parameter server.

[0081] For example, the system administrator of the risk control operation scheduling system writes or stores the login log information to be retrospectively analyzed into a parameter server to create a retrospective task. The historical data retrospective parameters may specifically include the prefix of the login log file name to be retrospectively analyzed, as well as a descriptive information about the purpose of the login log file. The parameter server can be deployed on the same server node as the risk control operation scheduling system.

[0082] In some embodiments, historical data backtracking parameters can be obtained from the system administrator of the risk control operation scheduling system to create a backtracking task. Alternatively, the system administrator of the risk control operation scheduling system can initiate a historical data backtracking request, which includes historical data backtracking parameters, to create a backtracking task. Specifically, the historical data backtracking parameters may include a prefix to the login log filename to be backtracked, and a description of the purpose of the login log file to be backtracked.

[0083] In some embodiments, the target login log can be stored in a log storage device and recorded by an authentication device. For example, the authentication device records the login information of accounts that have successfully logged in and undergone login risk identification during the login process within a target duration, and generates the target login log. The target duration can be flexibly set according to actual needs, and this application does not limit it.

[0084] In some embodiments, the login log file may be named as follows: <log file prefix>-<server identifier>-<log file time, and the format may be such as yyyymmddhh24>.log.

[0085] In the log file timestamps, "yyyy" represents the year, "mm" represents the month, "dd" represents the day, "hh" represents the hour, and "24" is in 24-hour format.

[0086] In some embodiments, the login log is in JSON format, with one log entry per process, and may contain fields as shown in Table 1, in sequence.

[0087] Table 1

[0088]

[0089] It should be noted that the contents contained in Table 1 above are merely examples. The login log in this application embodiment may also include more or fewer fields than those described in Table 1, and this application does not limit this.

[0090] The backtracking task created in this embodiment has the characteristics of being sequential (file time order, file content order), continuous, controllable, and having high throughput.

[0091] In S220, based on historical data backtracking parameters, part or all of the target login log lines are read from the log storage device, and each line of log information is parsed into a message to obtain a message set.

[0092] Specifically, the log storage device can be the aforementioned log storage device 140, which can be deployed independently or mounted on a local disk or NAS device for storing and managing log files collected from various IAM system nodes. It should have the capability to configure historical log file cleanup policies and schedule cleanup scripts to run. The system administrator of the risk control operation scheduling system specifies storage paths for registered login log files, records the storage path directory in the risk control operation scheduling system, and can detect whether the storage path directory exists and whether the risk control operation scheduling system has access permissions.

[0093] In some embodiments, the target login log information in the historical data backtracking parameters includes at least the start time, the initial line identifier, and the number of lines read. Specifically, the target login log is retrieved from the log storage device based on the start time; the initial line file is retrieved from the target login log based on the initial line identifier; starting from the initial line file, the line files in the target login log are read sequentially; each line of log information is parsed into a message; and the parsed message is stored in a log list (logList) deployed in the log storage device. Before reading each next line, the read task is terminated based on the number of lines read or the end identifier of the target login log; after reading is completed, a message set is obtained from the log list (logList).

[0094] In some embodiments, before reading the next line of the file, the number of parsed packets is obtained. If the number of parsed packets reaches the number of lines to be read, the reading task is terminated; otherwise, the next line of the target login log is read.

[0095] In some embodiments, before reading each next line of the file, the current line of the file is obtained. If the content of the current line of the file is the end marker of the target login log, the reading task is terminated; otherwise, the next line of the target login log is read.

[0096] For example, in the historical data backtracking parameters, the start time of the target login log (i.e., the earliest login log file time) is from_time, in the format yyyymmddhh24miss, the initial line identifier (i.e., the line number of the currently read file) is rownum, and the number of lines read is 1000. Based on from_time, the system searches the log storage device for the target login log (i.e., the log file to be read). If the target login log is not found, or the corresponding end identifier (e.g., for a chk file) does not exist, the system checks again after 1 minute to see if the target login log exists. If the target login log is found and the end identifier (e.g., for a chk file) exists, the initial line identifier from is defined as rownum, and the last line identifier to is defined as from + 1000. At the start of this batch of backtracking tasks, the system reads the content of the target login log line by line, starting from the from line, parses it into messages, and stores them in the log list (logList). Before reading each line of file content, first check if the target login log has been completely read (e.g., based on the end marker of the target login log). If it has been completely read, push the packets in the current logList's packet set to the risk identification device, preparing to read the next log file. If the target login log has not been completely read, check if the current logList depth has reached 1000. If it has, push the packet set in the logList to the risk identification device, clear the logList, and set from = to, to = from + 1; if it has not reached 1000, continue reading the next line of file content.

[0097] In some embodiments, after the messages in the message set are input into the risk identification device, the messages stored in the log list are cleared.

[0098] In some embodiments, the historical data backtracking parameter also includes an end time (i.e., the latest login log file time). Specifically, if the start time equals the end time, the backtracking task ends; if the start time is earlier than the end time, the start time is incremented by one to set a new start time, and the new initial read line identifier is set to one. The next login log line file is then read from the log storage device sequentially according to the new start time and the new initial read line identifier.

[0099] Specifically, in the historical data backtracking parameters, the start time of the target login log (i.e., the earliest login log file time) is from_time, in the format yyyymmddhh24miss, and the end time of the target login log (the latest login log file time) is end_time, in the format yyyymmddhh24miss. After the current file (i.e., the target login log) is read, before reading the next file, it is determined whether from_time is equal to end_time. If it is true, the backtracking task ends. If it is not true, from_time = from_time + 1 is set, the initial row identifier rownum = 1 is set, and these parameters are written to the parameter server. Then, the historical data backtracking parameter acquisition and the reading of the next file content from the log storage device in order according to from_time are executed in a loop.

[0100] In some embodiments, the historical data backtracking parameter also includes the number of concurrent processing threads. Specifically, a corresponding number of worker threads can be created for the backtracking task based on the number of concurrent processing threads. On each worker thread, the line file of the target login log is read from the log storage device according to the historical data backtracking parameter, and each line of log information read is parsed into a message. The messages parsed from all worker threads are then used to determine the message set. That is, multiple worker threads can be created for the same backtracking task to accelerate the reading rate of the login log file.

[0101] For example, in worker thread 1, log files containing lines 1-100 of the target login log are read from the log storage device, and each line of log information is parsed into a message and stored in the log list (logList); in worker thread 2, log files containing lines 101-200 of the target login log are read from the log storage device, and each line of log information is parsed into a message and stored in the log list (logList); in worker thread 3, log files containing lines 201-300 of the target login log are read from the log storage device, and each line of log information is parsed into a message and stored in the log list (logList); and so on, creating worker threads to satisfy the backtracking task.

[0102] In some embodiments, a certain number of worker threads are created for the backtracking task, and the current status of each worker thread is displayed (such as the row identifier read, progress information, read exception information, etc.).

[0103] In S230, the messages in the message set are input into the risk identification device to obtain the login risk identification result of the target login log output by the risk identification device.

[0104] Specifically, the risk identification device can be the aforementioned risk identification device 160, which may include risk control service 161, risk indicator calculation service 162, risk judgment service 163, risk indicator database 164, and risk event database 165, or may include risk control service 161, risk indicator calculation service 162, risk judgment service 163, and risk indicator database 164. This risk identification device can, according to predetermined risk control rules, accumulate risk control indicators using the content of each transaction message, and use the accumulated risk control indicators to perform risk judgment on the current transaction message.

[0105] In some embodiments, if the reading of the target login log is interrupted, a backtracking task interruption prompt is issued; after the backtracking task is resumed, the reading task of the target login log is resumed from the breakpoint.

[0106] Specifically, server downtime, changes in permissions of the target login log, or corruption of the target login log file may cause interruptions in reading the target login log. For example, after the risk control operation scheduling system issues a backtracking task interruption notification, the system administrator of the risk control operation scheduling system will analyze the anomaly information and handle the anomaly. After the anomaly is resolved, the backtracking task will be restarted. After the backtracking task is resumed, the risk control operation scheduling system will perform breakpoint continuation processing on the target login log reading task.

[0107] In some embodiments, backtracking task execution information is displayed, which includes at least one of the following: the date of the current backtracking file, backtracking progress, and the number of times line file read errors occurred.

[0108] In some embodiments, before inputting messages from the message set into the risk identification device, it is determined whether a job stop instruction has been received; specifically, if a job stop instruction is received, inputting messages from the message set into the risk identification device is stopped, and the backtracking task is stopped; if no job stop instruction is received, messages from the message set are input into the risk identification device, and the backtracking task continues to be executed.

[0109] Specifically, the operation stop instruction can be issued by the system administrator of the risk control operation scheduling system through the front end, which can flexibly control the execution status of the backtracking task.

[0110] In some embodiments, the aforementioned historical data backtracking parameters also include the number of backtracking tasks processed concurrently, corresponding to the above... Figure 4 The application architecture diagram is shown below. Specifically, a corresponding number of backtracking tasks can be created based on the number of concurrent backtracking tasks. In each backtracking task, a set of messages corresponding to a login log is obtained, and the obtained set of messages is input into the risk identification device. The login risk identification result output by the risk identification device for the login log in each backtracking task is also obtained.

[0111] Specifically, by creating a certain number of backtracking tasks, each backtracking task performs tasks such as reading different login log files and pushing messages, parallel processing of backtracking tasks is achieved, thereby improving the overall throughput.

[0112] In some embodiments, if the risk identification parameters set in the risk identification device change, a backtracking task for the target login log is recreated, and the risk identification effect of the newly set risk identification parameters in the risk identification device is compared and analyzed based on the login risk identification results output by the risk identification device for the message sets in the two backtracking tasks.

[0113] In other words, when the risk identification parameters (i.e., risk control rules) in the risk identification device change, the effect of the new risk identification parameters (i.e., risk control rules) can be predicted by reviewing the login logs over a specified time period. It has the advantages of being simple to implement and highly operable.

[0114] In some embodiments, a real-world test of the account security login solution showed that with 10 million login records, information could be read within 20 minutes and risk control services could be pushed out; the entire login risk identification process could be completed within 30 minutes, generating risk event data.

[0115] This application is applied to login risk control scenarios of identity authentication devices such as IAM / IDaaS, mainly targeting login risk indicators related to "time period", including risk control indicators such as "cumulative number of times", "cumulative duration" and "whether it has occurred before". Specific risk rules include "whether the number of failed login attempts is greater than 5 times in 1 hour", "whether the number of login attempts from the same IP address is greater than 10 times in 30 minutes", and "whether the account has been locked within a day".

[0116] Figure 6 An application flowchart according to an embodiment of this application is shown. Specific steps in the application flowchart can be executed by the system administrator and the risk control operation scheduling system. (Refer to...) Figure 6 As shown, it may include S10 to S19, which are described in detail below:

[0117] S10, the system administrator enters the prefix of the login log file name.

[0118] Specifically, the system administrator registers the prefix of the login log file name that needs to be backtracked in the risk control operation scheduling system, as well as the file's function description information. Of course, the system administrator can also register some other parameter information, which is not limited in this application.

[0119] S11, the system administrator enters the storage directory for the login log file.

[0120] Specifically, the system administrator specifies the storage path for the registered login log files and records the storage path directory in the risk control operation scheduling system. The system can also detect whether the directory exists and whether the risk control operation scheduling system has access permissions.

[0121] S12, the system administrator creates a rollback task.

[0122] Specifically, the system administrator creates a backtracking task in the risk control operation scheduling system. When creating the task, the administrator needs to specify the login log information to be backtracked and set the number of concurrent processes.

[0123] S13, the risk control operation scheduling system displays the preparation status of the backtracking task work thread.

[0124] Specifically, the risk control operation scheduling system creates a corresponding number of worker threads based on the number of concurrent processing requests and displays the current status of each worker thread. That is, multiple worker threads can be created for the same backtracking task to accelerate the reading speed of login log files.

[0125] S14, the system administrator initiates the backtracking task.

[0126] Specifically, the system administrator initiates the backtracking task and schedules worker threads to begin executing the task. The risk control operation scheduling system then displays the execution status of the specified backtracking task, including information such as the current backtracking file date, backtracking progress, and the number of access record reading anomalies.

[0127] For example, a corresponding number of worker threads can be created for the backtracking task based on the number of concurrent processing threads. On each worker thread, the login log line file is read from the log storage device according to the backtracking parameters, and each line of log information is parsed into a message. The messages parsed on all worker threads are determined as a message set, and the messages in the message set are pushed to the risk identification device to obtain the risk identification results for the login log.

[0128] S15, the risk control operation scheduling system displays the current status of the retrospective task execution.

[0129] Specifically, the risk control operation scheduling system can display the current execution status of the backtracking task, including the current backtracking file date, backtracking progress, number of access record reading anomalies, and other information.

[0130] S16, the risk control operation scheduling system issued an abnormal interruption reminder for the backtracking task.

[0131] Specifically, server crashes, changes in permissions of the target login log, or corruption of the target login log file may cause the backtracking task to be abnormally interrupted.

[0132] S17, the system administrator handles the exception.

[0133] Specifically, after receiving the notification of an abnormal interruption of the backtracking task, the system administrator analyzes the abnormal information and handles the abnormal situation.

[0134] S18, the system administrator restarted the rollback task.

[0135] Specifically, after the anomaly is resolved, the system administrator restarts the rollback task.

[0136] S19, the risk control operation scheduling system resumes the interrupted task and re-displays the execution status of the backtracking task.

[0137] Specifically, after the backtracking task is resumed, the risk control operation scheduling system performs breakpoint continuation processing on the login log reading task.

[0138] Figure 7 A system workflow diagram according to an embodiment of this application is shown. Specific steps in the system workflow can be executed by an identity authentication device, a log collection agent device, a risk control operation scheduling system, and a risk identification device. (Refer to...) Figure 7 As shown, it may include S21 to S29, which are described in detail below:

[0139] S21, the authentication device records the login log to a log file.

[0140] Specifically, the identity authentication device uses logging tools such as log4j to record each login log in real time in the order in which the login behavior occurs. The recording method is rolling, meaning that a log file is recorded for each time period. For example, the log file includes login information for accounts that have undergone login risk identification and successfully logged in during the login process within the target time period.

[0141] S22, The log collection agent collects login log files from the authentication device.

[0142] Specifically, the log collection agent continuously collects log files with specified log name prefixes from the specified log directory. The collection method can be streaming or overall.

[0143] S23, the log collection agent sends the login log file to the log storage device.

[0144] Specifically, the log collection agent continuously sends the collected login logs one by one to a designated directory on the log storage device. If sending fails, it needs to be resent. After three failures, a sending exception message is recorded in the system exception log (agent-error.log) for system operation and maintenance analysis. Login logs can be sent in either streaming or overall manner.

[0145] S24, the log collection agent sends the chk file to the log storage device.

[0146] Specifically, once a log file is successfully sent, a .chk file should also be sent to the designated directory on the log storage device to indicate that the log file transmission is complete. The .chk file should be named the same as the currently sent log file and should have the ".chk" extension.

[0147] S25, the risk control operation scheduling system executes a retrospective task.

[0148] Specifically, the risk control operation scheduling system initiates and executes backtracking tasks based on the system administrator's operation instructions.

[0149] S26, the risk control operation scheduling system reads the contents of the log file and obtains the message set.

[0150] Specifically, the backtracking task executes its tasks continuously and cyclically through a series of controlled workflows. Its main task is to read each line of each file in chronological order.

[0151] For example, based on the start time, the target login log is retrieved from the log storage device (the target login log includes login information of accounts that have successfully logged in and performed login risk identification during the login process within the target time period). Based on the initial line identifier, the initial line file to be read is retrieved from the target login log. Starting from the initial line file, the line files in the target login log are read sequentially. Each line of log information is parsed into a message, and the parsed message is stored in the log list (logList) deployed in the log storage device. Before reading the next line file, the reading task is terminated based on the number of lines read or the end identifier of the target login log. After the reading is completed, the message set is obtained from the log list (logList).

[0152] S27, the risk control operation scheduling system pushes the messages in the message set to the risk identification equipment in batches.

[0153] Specifically, the backtracking task will parse each line of transaction data into a message required for risk identification and push the message to the risk identification device in batches.

[0154] S28, the risk identification equipment accumulates risk control indicator data.

[0155] Specifically, the risk identification equipment accumulates risk control indicators based on the content of each transaction message according to the predetermined risk control rules (i.e., risk identification parameters).

[0156] S29, The risk identification device performs risk identification on the current login log.

[0157] Specifically, the risk identification device accumulates risk control indicators based on the content of each transaction message according to the predetermined risk control rules, and uses the accumulated risk control indicators to identify risks in the current login log.

[0158] Figure 8 A flowchart of a backtracking task workflow according to an embodiment of this application is shown. Specific steps in the backtracking task system workflow can be executed by a risk control operation scheduling system. The backtracking task is characterized by being sequential (file time order, file content order), continuous, controllable, and having high throughput. (Refer to...) Figure 8 As shown, the workflow of the backtracking task system may specifically include, for example: Figure 9 The details of S31 to S39 shown are as follows:

[0159] S31, obtain the basic parameters related to the login log file (i.e., the historical data backtracking parameters mentioned above) required for executing the backtracking task from the parameter server. Specifically, this may include:

[0160] The earliest login log file's time is from_time, in the format yyyymmddhh24miss;

[0161] The latest login log file's time, end_time, in the format yyyymmddhh24miss;

[0162] The row identifier (rownum) of the currently read login log file;

[0163] The number of lines read.

[0164] Specifically, all login log files to be read are arranged in chronological order, with the earliest file having a time value of from_time and the latest file having a time value of end_time. The current file is read from the row identifier rownum. The starting line identifier for reading file content in this batch is from, with a default value of 1. The last line identifier for reading file content in this batch is to.

[0165] S32, locate the login log file that needs to be read from the log storage device based on the earliest login log file's time.

[0166] In other words, the system searches for the login log file to be read from the log storage device based on `from_time`. Specifically, if the login log file is not found, or the corresponding .chk file does not exist, the system checks again after one minute to see if the login log file exists. If the login log file is found and the .chk file exists, the system defines the starting line identifier `from` as `rownum` and the ending line identifier `to` as `from + 1000`, meaning the number of lines read is 1000.

[0167] S33, This batch of tasks begins. Starting from the line identifier where the file content is read from this batch, the content of the current login log file is read line by line, parsed into messages, and stored in the log list.

[0168] In other words, at the start of this batch of tasks, the current login log file content is read line by line, starting from the `from` line, and parsed into risk identification messages, which are then stored in the log list (logList). Specifically, before reading the next line of file content, it is first determined whether the current login log file has been completely read. If it has been completely read, the messages in the message set stored in the current `logList` are pushed to the risk identification device, preparing to read the next login log file.

[0169] S34. If the login log file has not been completely read, determine whether to continue reading the log file based on the message depth of the current log list.

[0170] Specifically, if the login log file has not been completely read, it is determined whether the depth of the current log list has reached 1000. If it has, the messages in the message set stored in the log list are pushed to the risk identification device, the log list is cleared, and from = to, to = from + 1 is set; if it has not reached 1000, the next line of file content is read.

[0171] S35: Before pushing messages from the message set stored in each batch log list to the risk identification device, it first determines whether a work stop signal has been received from the system administrator through the front end. If so, the entire backtracking task is stopped.

[0172] Specifically, upon receiving a job stop instruction, the input of messages from the message set into the risk identification device is stopped, and the backtracking task is halted; conversely, if no job stop instruction is received, messages from the message set are input into the risk identification device, and the backtracking task continues. System administrators can flexibly control the execution of the backtracking task using job stop instructions.

[0173] S36. After the current login log file has been read, before reading the next login log file, determine whether to end the backtracking task based on the time of the earliest login log file and the time of the latest login log file.

[0174] Specifically, after the current login log file is read, before reading the next login log file, it is checked whether from_time is equal to end_time. If it is true, the backtracking task ends. If it is not true, from_time = from_time + 1 and rownum = 1, and these parameters are written to the parameter server. Then, S31 is executed in a loop to start reading the contents of the next login log file from the log storage device in order according to from_time.

[0175] Therefore, in this embodiment, for the target login log including login information of accounts that have successfully logged in and performed login risk identification during the login process within the target time period, part or all lines of the target login log are read from the log storage device according to historical data backtracking parameters. Each line of log information is parsed into a message, and the message is input into the risk identification device to obtain the login risk identification result of the target login log output by the risk identification device. This allows for backtracking of login information of accounts that have successfully logged in and performed login risk identification during the login process, achieving login risk identification based on historical login information backtracking. This results in more secure account login, decoupling login risk identification from the login process, achieving efficient post-login risk control, promoting refined division of labor in login risk control, reducing the pressure of real-time login risk monitoring, improving the efficiency of the identity authentication system, and achieving comprehensive and accurate login risk control when combined with real-time login risk control.

[0176] The above text combined Figures 5 to 9 The method embodiments of this application are described in detail below, in conjunction with... Figure 10 The present application describes the device embodiments in detail. It should be understood that the device embodiments correspond to the method embodiments, and similar descriptions can be referred to the method embodiments.

[0177] Figure 10 A block diagram schematically illustrates a secure account login device according to an embodiment of this application. The secure account login device may be a software unit or a hardware unit, or a combination of both, integrated into a computer device.

[0178] like Figure 10 As shown, the secure account login device 300 provided in this application embodiment may specifically include:

[0179] The acquisition module 310 is used to acquire historical data backtracking parameters. The historical data backtracking parameters include at least the information of the target login log. The target login log includes the login information of accounts that have performed login risk identification and successfully logged in during the login process within the target time period.

[0180] Processing model 320 is used to read part or all of the line files of the target login log from the log storage device according to the historical data backtracking parameters, and parse each line of log information read into a message to obtain a message set;

[0181] Input module 330 is used to input the messages in the message set into the risk identification device;

[0182] The acquisition module 310 is also used to acquire the login risk identification result of the target login log output by the risk identification device.

[0183] In one embodiment, the information in the target login log includes the start time, the identifier of the first line read, and the number of lines read; the processing model 320 is specifically used for:

[0184] Based on the start time, the target login log is retrieved from the log storage device. Based on the initial line identifier, the initial line file to be read is retrieved from the target login log. Starting from the initial line file, the lines in the target login log are read sequentially. Each line of log information is parsed into a message and stored in the log list deployed in the log storage device. Before reading the next line, the reading task is terminated based on the number of lines read or the end identifier of the target login log. After reading is completed, the message set is obtained from the log list.

[0185] In one embodiment, the processing model 320 is specifically used for:

[0186] Before reading each line of the file, the number of parsed packets is obtained. If the number of parsed packets reaches the number of lines to be read, the reading task is terminated; otherwise, the process continues reading the next line of the file. Alternatively...

[0187] Before reading each line of the file, retrieve the current line of the file. If the content of the current line of the file is the end marker of the target login log, determine to end the reading task; otherwise, continue reading the next line of the file.

[0188] In one embodiment, the historical data backtracking parameter also includes an end time, and the processing model 320 is further used for:

[0189] If the start time equals the end time, the backtracking task ends.

[0190] If the start time is earlier than the end time, increment the start time by one to set it as the new start time, and set the new initial read line identifier to one. Then, read the next login log line file from the log storage device in sequence according to the new start time and the new initial read line identifier.

[0191] In one embodiment, the processing model 320 is also used for:

[0192] After inputting the messages in this message set into the risk identification device, clear the messages stored in the log list.

[0193] In one embodiment, the historical data backtracking parameter also includes the number of threads for concurrent processing.

[0194] Model 320 is specifically used for:

[0195] Based on the number of concurrent processing threads, a corresponding number of worker threads are created for the backtracking task. On each worker thread, the line file of the target login log is read from the log storage device according to the historical data backtracking parameters, and each line of log information is parsed into a message. The messages parsed from all worker threads are determined as the message set.

[0196] In one embodiment, the processing model 320 is also used for:

[0197] If the reading of the target login log is interrupted, a backtracking task interruption prompt is issued; after the backtracking task is resumed, the task of reading the target login log is resumed from the breakpoint.

[0198] In one embodiment, the processing model 320 is also used for:

[0199] Displays backtracking task execution information, which includes at least one of the following: the date of the current backtracking file, backtracking progress, and the number of line file read exceptions that occurred.

[0200] In one embodiment, the processing model 320 is also used for:

[0201] Before inputting messages from this message set into the risk identification device, determine whether a work stop instruction has been received;

[0202] Upon receiving a stop instruction, stop inputting messages from that message set into the risk identification device and stop the backtracking task;

[0203] If no work stop instruction is received, the messages in this message set are input into the risk identification device, and the backtracking task continues to be executed.

[0204] In one embodiment, the historical data backtracking parameter also includes the number of backtracking tasks processed concurrently.

[0205] Model 320 is also used for:

[0206] Based on the number of concurrent backtracking tasks, a corresponding number of backtracking tasks are created. In each backtracking task, a message set corresponding to a login log is obtained. The obtained message set is then input into the risk identification device, and the login risk identification result output by the risk identification device for the login log in each backtracking task is obtained.

[0207] In one embodiment, the processing model 320 is also used for:

[0208] If the risk identification parameters set in the risk identification device change, recreate the backtracking task for the target login log, and compare and analyze the risk identification effect of the newly set risk identification parameters in the risk identification device based on the login risk identification results output by the risk identification device for the message sets in the two backtracking tasks.

[0209] The specific implementation of each module in the secure login device for accounts provided in this application embodiment can refer to the content of the secure login method for accounts described above, and will not be repeated here.

[0210] The modules in the aforementioned secure login device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to these modules.

[0211] Figure 11 A schematic diagram of the structure of a computer system implementing an electronic device according to an embodiment of this application is shown. It should be noted that... Figure 11 The computer system 400 of the electronic device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0212] like Figure 11 As shown, the computer system 400 includes a Central Processing Unit (CPU) 401, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 402 or programs loaded from storage section 408 into Random Access Memory (RAM) 403. The RAM 403 also stores various programs and data required for system operation. The CPU 401, ROM 402, and RAM 403 are interconnected via a bus 404. An Input / Output (I / O) interface 405 is also connected to the bus 404.

[0213] The following components are connected to I / O interface 405: an input section 406 including a keyboard, mouse, etc.; an output section 407 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 408 including a hard disk, etc.; and a communication section 409 including a network interface card such as a local area network (LAN) card, modem, etc. The communication section 409 performs communication processing via a network such as the Internet. A drive 410 is also connected to I / O interface 405 as needed. A removable medium 411, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 410 as needed so that computer programs read from it can be installed into storage section 408 as needed.

[0214] Specifically, according to embodiments of this application, the processes described in the flowcharts above can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts above. In such embodiments, the computer program can be downloaded and installed from a network via communication section 409, and / or installed from removable medium 411. When the computer program is executed by central processing unit (CPU) 401, it performs the various functions defined in the apparatus of this application.

[0215] In one embodiment, an electronic device is also provided, comprising:

[0216] Processor; and

[0217] Memory for storing the executable instructions of the processor;

[0218] The processor is configured to execute the steps in the above method embodiments by executing executable instructions.

[0219] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0220] In one embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0221] It should be noted that the computer-readable storage medium described in this application can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, disk storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable storage medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, radio frequency, etc., or any suitable combination thereof.

[0222] This embodiment is only used to illustrate this application. The selection of software and hardware platform architecture, development environment, development language, message acquisition source, etc. in this embodiment can be varied. Based on the technical solution of this application, any improvement or equivalent transformation made to a certain part according to the principle of this application should not be excluded from the protection scope of this application.

[0223] It should be noted that the terminology used in the embodiments of this application and the appended claims is for the purpose of describing specific embodiments only, and is not intended to limit the embodiments of this application.

[0224] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of the embodiments of this application.

[0225] If 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 embodiment, essentially, or the part that contributes to the prior art, or a 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 method described in the embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks.

[0226] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the devices, apparatuses, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0227] In the several embodiments provided in this application, it should be understood that the disclosed electronic devices, apparatuses and methods can be implemented in other ways.

[0228] For example, the division of units, modules, or components in the device embodiments described above is merely a logical functional division. In actual implementation, there may be other division methods. For example, multiple units, modules, or components may be combined or integrated into another system, or some units, modules, or components may be ignored or not executed.

[0229] For example, the units / modules / components described above as separate / display components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the units / modules / components can be selected to achieve the objectives of the embodiments of this application, depending on actual needs.

[0230] Finally, it should be noted that the mutual coupling or direct coupling or communication connection shown or discussed above can be an indirect coupling or communication connection through some interface, device or unit, and can be electrical, mechanical or other forms.

[0231] The above description is merely a specific implementation of the embodiments of this application, but the protection scope of the embodiments of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the embodiments of this application should be included within the protection scope of the embodiments of this application. Therefore, the protection scope of the embodiments of this application should be determined by the protection scope of the claims.

Claims

1. A secure login method for an account, characterized in that, include: Obtain historical data backtracking parameters, which include at least the information of the target login log, the number of concurrent processing threads and / or the number of concurrent processing backtracking tasks. The target login log includes login information of accounts that have successfully logged in and whose login risk identification has been performed during the login process within the target time period. Based on the historical data backtracking parameters, some or all lines of the target login log are read from the log storage device, and each line of log information is parsed into a message to obtain a message set; Before inputting messages from the message set into the risk identification device, determine whether a work stop instruction has been received; Upon receiving a job stop instruction, stop inputting messages from the message set into the risk identification device and stop the backtracking task; If no job stop instruction is received, the messages in the message set are input into the risk identification device, and the backtracking task continues to be executed to obtain the login risk identification result of the target login log output by the risk identification device; If the risk identification parameters set in the risk identification device change, a new backtracking task for the target login log is created, and the risk identification effect of the newly set risk identification parameters in the risk identification device is compared and analyzed based on the login risk identification results output by the risk identification device for the message sets in the two backtracking tasks.

2. The method according to claim 1, characterized in that, The target login log information includes the start time, the initial line identifier read, and the number of lines read; The step involves reading part or all of the target login log lines from the log storage device based on the historical data backtracking parameters, and parsing each line of log information into a message to obtain a message set, including: The target login log is retrieved from the log storage device based on the start time. The initial line file to be read is retrieved from the target login log based on the initial line identifier. Starting from the initial line file, the line files in the target login log are read sequentially. Each line of log information is parsed into a message and stored in the log list deployed in the log storage device. Before reading the next line, the reading task is terminated based on the number of lines read or the end identifier of the target login log. After reading is completed, the message set is obtained from the log list.

3. The method according to claim 2, characterized in that, The step of determining whether to end the reading task before reading each next line of the file, based on the number of lines read or the end identifier of the target login log, includes: Before reading each next line of the file, the number of parsed packets is obtained. If the number of parsed packets reaches the number of lines to be read, the reading task is terminated; otherwise, the next line of the file is read. Before reading each line of the file, retrieve the current line of the file. If the content of the current line of the file is the end marker of the target login log, determine to end the reading task; otherwise, continue reading the next line of the file.

4. The method according to claim 2, characterized in that, The historical data backtracking parameters also include an end time, and the method further includes: If the start time equals the end time, the backtracking task ends. If the start time is earlier than the end time, the start time is incremented by one to set a new start time, and the new initial read line identifier is set to one. The next login log line file is then read from the log storage device in sequence according to the new start time and the new initial read line identifier.

5. The method according to claim 2, characterized in that, The method further includes: After inputting the messages from the message set into the risk identification device, the messages stored in the log list are cleared.

6. The method according to claim 1, characterized in that, The step involves reading part or all of the target login log lines from the log storage device based on the historical data backtracking parameters, and parsing each line of log information into a message to obtain a message set, including: Based on the number of concurrent processing threads, a corresponding number of worker threads are created for the backtracking task. On each worker thread, the line file of the target login log is read from the log storage device according to the historical data backtracking parameters, and each line of log information is parsed into a message. The messages parsed on all worker threads are determined as the message set.

7. The method according to claim 1, characterized in that, The method further includes: If the reading of the target login log is interrupted, a backtracking task interruption prompt is issued; after the backtracking task is resumed, the task of reading the target login log is resumed from the breakpoint.

8. The method according to claim 1, characterized in that, The method further includes: Display the backtracking task execution information, which includes at least one of the following: the date of the current backtracking file, the backtracking progress, and the number of times a line file read exception occurred.

9. The method according to claim 1, characterized in that, The method further includes: Based on the number of concurrent backtracking tasks, a corresponding number of backtracking tasks are created. In each backtracking task, a message set corresponding to a login log is obtained, and the obtained message set is input into the risk identification device. The login risk identification result output by the risk identification device for the login log in each backtracking task is also obtained.

10. A secure login device for an account, characterized in that, include: The acquisition module is used to acquire historical data backtracking parameters. The historical data backtracking parameters include at least the information of the target login log, the number of concurrent processing threads and / or the number of concurrent processing backtracking tasks. The target login log includes the login information of accounts that have successfully logged in and performed login risk identification during the login process within the target time period. The processing model is used to read part or all of the line files of the target login log from the log storage device according to the historical data backtracking parameters, and parse each line of log information read into a message to obtain a message set; Before inputting messages from the message set into the risk identification device, determine whether a job stop instruction has been received; if a job stop instruction has been received, stop inputting messages from the message set into the risk identification device and stop the backtracking task. The input module is used to input the messages in the message set into the risk identification device and continue to execute the backtracking task if no work stop instruction is received; The acquisition module is also used to acquire the login risk identification result of the target login log output by the risk identification device; The processing model is also used to recreate a backtracking task for the target login log when the risk identification parameters set in the risk identification device change, and to compare and analyze the risk identification effect of the newly set risk identification parameters in the risk identification device based on the login risk identification results output by the risk identification device for the message sets in the two backtracking tasks.

11. An electronic device, characterized in that, include: processor; as well as Memory for storing the executable instructions of the processor; The processor is configured to perform the method of any one of claims 1 to 9 by executing the executable instructions.

12. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 9.

Images