CN112613029A - Weak password detection method and device, computer storage medium and equipment - Google Patents

Abstract

The embodiments of the present application disclose a weak password detection method, device, computer storage medium, and device. The method includes: receiving login request information; determining a login feature rule corresponding to the login request information; The login information is extracted from the login request information; when it is detected that the login status is successful login, weak password detection is performed on the login information to determine whether there is a weak password in the login information. In this way, by determining the login feature rules for the login request information, the login information can be accurately extracted from the login request information based on the login feature rules; and when the login is successful, by performing weak password detection on the login information, it is also possible to Improve the detection rate of weak passwords, while reducing the misjudgment rate of weak passwords.

Description

A weak password detection method, device, computer storage medium and device

technical field

The present application relates to the technical field of network security, and in particular, to a weak password detection method, apparatus, computer storage medium, and device.

Background technique

Weak passwords refer to passwords that are easily guessed by malicious users or cracked by cracking tools, such as passwords that only contain simple numbers and letters, such as "123", "abc", and so on. According to statistics, about 30% of security problems are caused by weak passwords, and most enterprises have the need for password inspection and supervision. Therefore, weak password management has become a very important part of enterprise security construction. However, in the related art, the currently commonly used weak password detection methods have insufficient ability to detect weak passwords, so there are problems of a low detection rate of weak passwords and a high misjudgment rate.

SUMMARY OF THE INVENTION

The present application provides a weak password detection method, device, computer storage medium and device, which can accurately identify weak passwords under various login components, thereby improving the detection rate of weak passwords and reducing the misjudgment rate of weak passwords.

The technical solution of the present application is realized as follows:

In a first aspect, an embodiment of the present application provides a weak password detection method, the method comprising:

Receive login request information;

determining the login feature rule corresponding to the login request information;

extracting login information from the login request information based on the login feature rule;

When it is detected that the login status is successful login, weak password detection is performed on the login information to determine whether there is a weak password in the login information.

In a second aspect, an embodiment of the present application provides a weak password detection device, the weak password detection device includes: a receiving unit, a determining unit, an extracting unit, and a detecting unit; wherein

the receiving unit, configured to receive login request information;

The determining unit is configured to determine the login feature rule corresponding to the login request information;

The extraction unit is configured to extract login information from the login request information based on the login feature rule;

The detection unit is configured to perform weak password detection on the login information when it is detected that the login status is successful login, so as to determine whether there is a weak password in the login information.

In a third aspect, an embodiment of the present application further provides a weak password detection device, the weak password detection device includes: a memory and a processor; wherein,

the memory for storing a computer program executable on the processor;

The processor is configured to execute the weak password detection method according to the first aspect when running the computer program.

In a fourth aspect, an embodiment of the present application provides a computer storage medium, where the computer storage medium stores a weak password detection program, and the weak password detection program implements the weak password according to the first aspect when the weak password detection program is executed by at least one processor Detection method.

In a fifth aspect, an embodiment of the present application provides a detection device, where the detection device includes at least the weak password detection apparatus described in the second aspect or the third aspect.

A weak password detection method, device, computer storage medium, and device provided by the embodiments of the present application receive login request information; determine a login feature rule corresponding to the login request information; The login information is extracted from the request information; in the case that the login status is detected as successful login, weak password detection is performed on the login information to determine whether there is a weak password in the login information. In this way, after receiving the login request information, by determining the login feature rules corresponding to the login request information, the feature rules corresponding to different login components can be accurately identified, and the login information to be detected can be accurately extracted, and then the login information can be processed. When detecting weak passwords, it can accurately identify weak passwords under various login components, improve the detection rate of weak passwords, and reduce the misjudgment rate of weak passwords.

Description of drawings

1 is a schematic flowchart of a weak password detection method provided by an embodiment of the present application;

2 is a schematic flowchart of another weak password detection method provided by an embodiment of the present application;

3 is a schematic diagram of the composition and structure of a weak password detection system provided by an embodiment of the present application;

FIG. 4 is a schematic structural diagram of a weak password detection device provided by an embodiment of the present application;

5 is a schematic structural diagram of another weak password detection device provided by an embodiment of the present application;

FIG. 6 is a schematic diagram of the hardware structure of a weak password detection device provided by an embodiment of the present application;

FIG. 7 is a schematic structural diagram of the composition of a detection device provided by an embodiment of the present application.

Detailed ways

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application.

Weak password management has become a very important part of enterprise security construction. However, there is no product in the industry that can accurately identify weak passwords of various login components. At present, there are problems of low detection rate of weak passwords and high misjudgment rate. In the related art, when detecting weak passwords, the exhaustive method is usually used to perform multiple simulated logins, which leads to long detection time, low detection efficiency and high missed detection rate. damage, resulting in lower security.

It can be understood that Snort is a powerful network intrusion detection / Defense System (Network Intrusion Detection/Prevention System, NIDS). Most intrusion behaviors have certain characteristics, and Snort can detect many different intrusion behaviors and detection activities by using rule-based rule matching on data packets. The embodiment of the present application proposes to combine Snort rules with login components, different login components can be identified through Snort rules, and then login information can be accurately extracted according to the characteristic rules of different login components, so as to realize accurate detection of weak passwords of different login components.

Based on this, an embodiment of the present application provides a weak password detection method, the basic idea of which is: by receiving login request information; determining a login feature rule corresponding to the login request information; The login information is extracted from the login request information; when it is detected that the login status is a successful login, weak password detection is performed on the login information to determine whether there is a weak password in the login information. In this way, after receiving the login request information, by determining the login feature rules corresponding to the login request information, the feature rules corresponding to different login components can be accurately identified, and the login information to be detected can be accurately extracted, and then the login information can be processed. When detecting weak passwords, it can accurately identify weak passwords under various login components, improve the detection rate of weak passwords, and reduce the misjudgment rate of weak passwords.

In an embodiment of the present application, referring to FIG. 1 , it shows a schematic flowchart of a weak password detection method provided by an embodiment of the present application. As shown in Figure 1, the method may include:

S101: Receive login request information.

It should be noted that, the weak password detection method provided by the embodiment of the present application may be applied to a weak password detection device, or a detection device integrated with the device. Here, the detection device may be, for example, a smart phone, a tablet computer, a notebook computer, a palmtop computer, a personal digital assistant (Personal Digital Assistant, PDA), a navigation device, a server, etc., which is not specifically limited in this embodiment of the present application.

It should also be noted that the weak password detection method provided by the embodiments of the present application may be applicable to a World Wide Web (WorldWide Web, Web) system. For example, when a user performs a login operation through a browser, client, etc., the browser or client first receives the login request information. Here, it is only listed that the user logs in through a browser, a client terminal, etc. In practice, there are multiple login methods, which are not specifically limited in this embodiment of the present application.

S102: Determine a login feature rule corresponding to the login request information.

It should be noted that, in this embodiment of the present application, after the login request information is received, the corresponding login feature rule may be determined based on the received login request information. Specifically, it can be as follows: perform feature extraction on the login request information, and match it with a preset feature rule base. If it matches a certain login feature rule successfully, it can be determined that the login feature rule corresponding to the login request information is matched successfully. Login feature rules for .

S103: Extract login information from the login request information based on the login feature rule.

It should be noted that, in this embodiment of the present application, after the login feature rule is determined, the login information can be extracted from the login request information based on the determined login feature rule. Since the login feature rule has been determined according to the login request information in step S102, the login information can be accurately extracted from the login request information based on the login feature rule. Here, the login information may include at least a user name and a password.

S104: In the case where it is detected that the login status is successful login, perform weak password detection on the login information to determine whether there is a weak password in the login information.

It should be noted that, in the embodiment of the present application, after the login information is extracted from the login request information based on the determined login feature rules, the login can be performed based on the extracted login information, for example, based on the extracted user name and password. To log in, you need to check the login status at this time. If the detection result shows that the login status is successful login, it means that the password in the login information is correct. At this time, it is necessary to perform weak password detection on the login information to determine whether there is a weak password in the login information. It can be understood that if the login status is failed, it means that the user name or password is incorrect, and in this case, there is no need to perform weak password detection on the login information.

That is to say, the embodiment of the present application only performs weak password detection on the login information that has been successfully logged in, which not only reduces the pressure on the website under test, but also improves the efficiency of weak password detection.

The embodiment of the present application provides a weak password detection method, by receiving login request information; determining a login feature rule corresponding to the login request information; extracting login information from the login request information based on the login feature rule; When it is detected that the login status is successful login, weak password detection is performed on the login information to determine whether there is a weak password in the login information. In this way, after receiving the login request information, by determining the login feature rules corresponding to the login request information, the feature rules corresponding to different login components can be accurately identified, and the login information to be detected can be accurately extracted, and then the login information can be processed. When detecting weak passwords, it can accurately identify weak passwords under various login components, improve the detection rate of weak passwords, and reduce the misjudgment rate of weak passwords.

In another embodiment of the present application, referring to FIG. 2 , it shows a schematic flowchart of another weak password detection method provided by an embodiment of the present application. As shown in Figure 2, the method may include:

S201: Receive login request information.

It should be noted that the description of the implementation process of step S201 is consistent with the description of the implementation process of step S101 in the previous embodiment, which is not repeated in this embodiment of the present application.

S202: Identify the login request information by using a preset identification rule, and determine the component information to be logged in.

S203: Based on the component information to be logged in, determine the login feature rule corresponding to the component information to be logged in from a preset rule base.

Here, the preset rule base includes multiple types of login component information and respective login feature rules corresponding to the multiple types of login component information. In some embodiments, determining the login feature rule corresponding to the component information to be logged in from a preset rule base based on the component information to be logged in may include:

Perform feature matching between the component information to be logged in and the preset rule base;

According to the matching result, the login feature rule is determined from the preset rule base.

It should be noted that, in this embodiment of the present application, after receiving the login request information, the login request information can be identified by using a preset identification rule, so as to determine the component information to be logged in, and further determine the component information to be logged in according to the information of the component to be logged in. The log-in feature rule corresponding to the log-in request information is displayed.

In this embodiment of the present application, the preset identification rules may include Snort rules.

Here, Snort rules are the core modules of the Snort engine, which can identify and extract features for certain behaviors. In this embodiment of the present application, the Snort rule may be used to identify the features of the login request information, and of course other identification rules may also be used to identify the features of the login request information, which is not specifically limited in this embodiment. After identifying the component information to be logged in, the extracted component information to be logged in is matched with the preset rule base in the Snort engine. The preset rule base contains a variety of common login components and corresponding login feature rules. User-defined login components and corresponding login feature rules may also be included. It should also be noted that the preset rule base belongs to a part of the Snort engine, which can also be called feature matching through Snort rules to determine the log-in feature rules corresponding to the log-in request information.

In this way, after the component information to be registered is determined, the component information to be registered can be matched with the preset rule base; if the matching is successful, the corresponding login feature rule can be determined.

Further, in some embodiments, the preset rule base may include a first feature rule base and a second feature rule base; wherein the first feature rule base represents a feature rule base corresponding to common login components, and the second feature rule base The library represents the predefined configuration feature rule library corresponding to the uncommon login components.

Specifically, the first feature rule base represents a feature rule base corresponding to common login components. Common login components may be Joomla, EYOUCMS, DedeCMS, DouPHP, and other common login components, and are not limited to the examples here. For example, when the login component is Joomla, the login process of Joomla is completed by the component com_user, the plugin plugin/authenication/joomla.php, plugin/user/joomla.php and many other parts. When the user logs in, the user component is in the After accepting the user's login request, the login authentication process is initiated. The login request information can be a piece of program code, the focus of which is $options and $credentials. The former records some client behaviors such as remember me (remembe me), return address, and the latter Similar to an identity request token, the token includes the username and password entered by the user. It should be noted that the Joomla login component is used as an example here. In practice, there are many common login components corresponding to different login feature rules.

The second feature rule base represents a predefined configuration feature rule base corresponding to the uncommon login component. For example, for some enterprises or companies, users do not use common login components to log in, but internal business login systems or private login components developed or purchased by the company. These login components are only used in It is used within an enterprise or company or within a small range, and does not exist in the first feature rule base. At this time, users can add these unusual login component information and their corresponding pre-configured login feature rules to the second feature rule by themselves. In the library, users can update it by themselves or automatically online, which satisfies the customization of the internal business login system and private login component information and their corresponding login feature rules.

For example, when company W manages the company system, it uses the internal business login system K developed by the company itself, and can also use the purchased private login component L. In addition, it sometimes uses some common login components. In this way, for company W, the internal business login system K, the private login component L and the corresponding login feature rules can be added to the second feature rule base. In this way, when an employee logs in, the weak password detection device will first identify the login request information to determine the login component information, and then accurately extract the username and password according to the login feature rules corresponding to the current login component. In the subsequent use process, if a new component is developed or purchased, or a new version of the login component is updated, the second feature rule base can be updated automatically or manually.

It can be seen that if the login component information is identified before the login information is extracted, and then according to the login feature rules corresponding to the login component information, the location of the login information such as user name and password can be accurately known and extracted accurately. After that, you can find out that the corresponding password in the database matches the user password according to the user name entered by the user. If the match is consistent, the login is successful, and if the match is inconsistent, the login fails. Different login components have different login feature rules. When receiving login request information, first perform feature extraction on the login request information to determine the component information to be logged in according to the preset identification rules, and further determine the login component information. Corresponding login feature rules, thereby accurately extracting login information from login request information based on login feature rules unique to different login component information.

In this embodiment of the present application, the first feature rule base may be preset inside the weak password detection apparatus (or detection device). In some embodiments, for the first feature rule base, the method may further include: online updating the first feature rule base.

That is to say, due to the continuous development of industry technology, more and different types of components will be developed; and the login components already included in the first feature rule base will also be continuously updated with new versions. Therefore, in this embodiment of the present application, the first feature rule base also supports online update.

In this embodiment of the present application, the online update to the first feature rule base includes updating the type of login component information and updating the type of login feature rule corresponding to the login component information. The update may be real-time, regular or irregular, which is not specifically limited in this embodiment. For example, the first feature rule base originally contains M different types of login component information. A company has developed a new login component and widely used it. When the new login component is detected during online update, it will The new login component information and its corresponding login feature rules are added to the first feature rule base for updating. For another example, the login component information A that originally existed in the first feature rule base, a new version A2.0 was released after a period of time, and the new version A2.0 added new login feature rules that did not exist in A before, When a new login feature rule in the A2.0 is detected during online update, the new login feature rule will be added to the first feature rule base for updating. Of course, the updating of the first feature rule base is not limited to the examples listed here, and those skilled in the art can also take other means to update the first feature rule base.

S204: Extract login information from the login request information based on the login feature rule.

It should be noted that different login component information corresponds to different login feature rules. In this way, according to the determined log-in feature rule corresponding to the component information to be logged in, the log-in information can be accurately extracted from the log-in request information according to the log-in feature rule. Here, the login information may at least include: user name, password, source IP address, destination IP address, login time, and the like. Usually, the login information generally refers to the user name and password, but is not specifically limited.

S205: In the case where it is detected that the login status is successful login, perform weak password detection on the login information to determine whether there is a weak password in the login information.

In the embodiment of the present application, after the login information is extracted from the login request information, the login status can be determined based on the extracted login information at this time, and the login status may be success or failure, or even due to reasons such as the network other login states resulting. In this embodiment of the present application, only when it is detected that the login status is successful login, weak password detection is performed on the login information to determine whether there is a weak password in the login information. Specifically, the weak password detection on the login information is mainly to perform weak password detection on the password in the login information.

Further, in some embodiments, when it is detected that the login status is successful login, the method may further include:

writing the login information into the audit log table;

Correspondingly, the performing weak password detection on the login information may include:

Start the offline detection process;

The login information is obtained from the audit log table, and weak password detection is performed on the login information by using a preset detection strategy.

It should be noted that, in the embodiment of the present application, after it is detected that the login status is that the login is successful, the login information is written into the audit log table, and the audit log table is used to store the login information of the successful login. The login information stored in the audit log table includes at least the user name, password, and login status, and may also include the source IP address, destination IP address, and other login information. The weak password detection mainly uses the user name and password.

It should also be noted that, in this embodiment of the present application, after the login information is written into the audit log table, the offline detection process can be started regularly, such as every hour or every day, or it can be started irregularly, such as when an audit is detected. It starts when a preset number or range of login information is added to the log table, or it can be started manually, for example, when the administrator considers it necessary to manually start the offline detection process. After the offline detection process is started, a preset detection strategy is used to perform weak password detection on the login information. Here, the weak password detection is mainly performed on the password in the login information.

Further, in some embodiments, the offline detection process mainly includes preprocessing and weak password detection.

It should be noted that, in the embodiment of the present application, the offline detection process first preprocesses the collected data, that is, performs data screening on the login information read from the audit log table, and collects useful data for weak password verification. Detection, the useful data here mainly refers to the user name and password. Then, the offline detection process performs weak password detection on the login information. The weak password detection is to analyze and detect the collected data. Here, the weak password detection is mainly performed on the password.

Further, in some embodiments, the preset detection strategy includes a built-in weak password detection strategy and a predefined weak password detection strategy; wherein,

The built-in weak password detection strategy includes at least one of the following: a built-in password length detection strategy, a built-in character type detection strategy, and a common component weak password dictionary matching detection strategy;

The predefined weak password detection strategy includes at least one of the following: a preset password length detection strategy, a preset character type detection strategy, and a preset weak password dictionary matching detection strategy.

It should be noted that, in the embodiment of the present application, the built-in weak password detection strategy includes at least one of the following: a built-in password length detection strategy, a built-in character type detection strategy, and a common component weak password dictionary matching detection strategy.

Further, in some embodiments, the method may further include: updating the built-in weak password detection policy.

It should be noted that, in this embodiment of the present application, the built-in weak password detection strategy may be preset inside the weak password detection device (or detection device) and updated regularly or irregularly, and the update may include detecting the built-in password length. , One or several strategies in the built-in character type detection strategy and the common component weak password dictionary matching detection strategy, and the update of the built-in weak password detection strategy other than these strategies.

It should be noted that when the password is too short, for example, it only includes four characters, it is more likely to be cracked. Through the built-in password length detection strategy, weak passwords can be detected because the password length does not conform to the strategy. For example, a length threshold or length interval can be set, and when the password length is less than the threshold or not in the interval, it means that the password strength is relatively weak. An example is as follows: When the built-in password length detection policy specifies that the password length should be greater than or equal to 6 characters, a password of A24b is detected at this time, which only contains four characters, that is, the password length is too short, so it may be cracked. At this time, it can be determined as a weak password according to the built-in password length detection strategy. It should be noted that with the development of industry technology, password cracking methods will become more and more advanced. It may be safer to set the character length to 6 characters, but in some cases, it may be possible to set the character length to 6 characters. It is no longer secure, so the built-in password length detection strategy will be updated based on the actual situation, and the update can be real-time, regular or irregular.

It should be noted that a password with a single character type is more likely to be cracked. The built-in character type detection strategy can detect passwords that are easy to be cracked due to a single character type. For example, the character types of the password can be limited, for example, the password includes at least S characters (S is an integer greater than 1), or the password includes at least several types of uppercase letters, lowercase letters, numbers, and symbols. If the character type of the password does not meet the requirements, it means that the password is weak and easy to be cracked, and may be a weak password. For example, when the built-in character type detection policy specifies that there are no less than 3 types of characters, and at least contains uppercase letters and lowercase letters, a password with the password FGH17895 is detected, which only contains uppercase letters and numbers. If it does not contain lowercase letters, it does not conform to the built-in character type detection strategy exemplified here. In this case, it can be determined as a weak password according to the built-in character type detection strategy. It should be noted that with the development of industry technology, password cracking methods will become more and more advanced. It may be safer to have three types of characters, but in some cases, three types of characters may already be used. It is no longer safe, so the built-in character type detection strategy will be updated according to the actual situation, and the update can be real-time, regular or irregular.

It should be noted that some users often choose some simple or regular passwords for the convenience of memory, such as "123456", "ABCDEF", "8888888", etc., or similar to "ZXCVBN" although it seems irregular , but the passwords are actually set in the order of the English keyboard, which are easy to guess or crack. Some hackers will use the weak password dictionary to try to log in to the account for many times until the correct password (ie "brute force cracking") is tried. Through the built-in weak password dictionary matching detection strategy of common components, passwords that are easily cracked by brute force can be detected. Match the password to be tested with the preset weak password dictionary of common components. If the match is successful, the password is a weak password. The weak password dictionary of common components can be composed of weak passwords obtained from the Internet and other channels, passwords found during blasting detection, and other common weak passwords, and the weak password dictionary of common components will be updated in real time or regularly or irregularly. When it is detected that an account is logging in and the login fails, the user may have entered the wrong password at this time, but it is also possible that a hacker or malware is brute force cracking the account. If brute force cracking is detected, it means that the detection The obtained password has been used to crack the account. If a user uses this password as the login password, it is very easy to be cracked. At this time, if the password does not exist in the preset weak password dictionary of common components, it will be added to the preset password. Suppose the common component weak password dictionary, for example, a new weak password dictionary appears on the Internet, and the weak passwords are added to the common component weak password dictionary. Of course, there are many ways to update the common component weak password dictionary, not limited to In the examples listed in the embodiments of the present application, as long as the weak password detection device detects a weak password that does not exist in the weak password dictionary of common components, a new weak password is added to update the weak password dictionary of common components.

In addition, the weak password detection device may also have a built-in password complexity detection strategy. For example, the password complexity detection strategy specifies that consecutive letters or numbers or a password identical to the user name is a weak password.

It should be noted that, in this embodiment of the present application, weak password detection may be performed on passwords simultaneously through several built-in weak password detection strategies, or weak password detection may be performed on passwords only through one or several built-in weak password detection strategies. This embodiment of the present application does not specifically limit this.

It should be noted that, in this embodiment of the present application, the predefined weak password detection strategy includes at least one of the following: a preset password length detection strategy, a preset character type detection strategy, and a preset weak password dictionary matching detection strategy .

Among them, the preset password length detection strategy and the preset character type detection strategy are similar to the built-in password length detection strategy and the built-in character type detection strategy in the built-in weak password detection strategy, and are mainly set by users according to their actual needs. Here No longer.

The preset weak password dictionary matching detection strategy is user-defined. The preset weak password dictionary can include weak passwords entered by the user, or a weak password dictionary generated according to the rules specified by the user; for example, the phone number of a company is A string of 8-digit and discontinuous numbers. For non-company people, setting the phone number as a password may not be easy to crack, but for employees of the company, if the phone number is directly set as a password or It is easy to crack by setting your name + this phone number as a password. Therefore, the default weak password dictionary is generally for users to add passwords that are easy to be cracked according to their actual situation. For example, users can add information such as the employee's name in pinyin or initials, phone number, public phone number, company name in pinyin or initials, etc. It is directly added to the preset weak password dictionary as a weak password, or a program can be used to combine it to generate a weak password and add it to the weak password dictionary. Similarly, the preset weak password dictionary also supports real-time or regular or irregular updates. Users can directly manually add new weak passwords or generate new weak passwords into the preset weak password dictionary based on their own conditions. For example, when a new employee joins the company, the company's internal system (the system includes the weak password detection device described in the embodiment of the present application) will input the information of the new employee. A weak password that is easily cracked can be generated according to the information and added to the preset weak password dictionary when making a phone call, etc.; of course, the user can also manually add a new weak password into the preset weak password dictionary. This is not specifically limited.

In addition, the user can also customize a preset password complexity detection strategy, for example, the password complexity detection strategy specifies that consecutive letters or numbers are weak passwords.

It should be noted that, in this embodiment of the present application, weak password detection may be performed on passwords simultaneously through several predefined weak password detection strategies, or weak password detection may be performed on passwords only through one or several predefined weak password detection strategies. Detection is not specifically limited in this embodiment of the present application.

It should be noted that, in this embodiment of the present application, weak password detection can be performed on passwords simultaneously through a built-in weak password detection strategy and a predefined weak password detection strategy, or only one of the detection strategies can be selected to perform weak password detection on passwords. , which is not specifically limited in the embodiments of the present application. For example, some users do not set a preset predefined weak password detection policy. In this case, only weak password detection needs to be performed according to the built-in weak password detection policy.

Further, in some embodiments, the login information includes a user name and a password, and after acquiring the login information from the audit log table, the method may further include:

Perform privileged account identification on the login information to determine whether the user name is a privileged account.

It should be noted that, in this embodiment of the present application, when performing weak password detection, the login information may include at least a user name and a password.

It should also be noted that a privileged account is often an account with higher operating authority, and a privileged account can be the system maintenance, authority increase, data, etc. assigned to relevant business operation, system management, system operation and maintenance personnel during the operation of the enterprise. Modify, delete, export and other high-level system accounts. These accounts and their holders control the life and death plan of the company's information system and escort the normal development of the company's various businesses. cause great harm.

Further, in some embodiments, the method for identifying a privileged account may include: identifying a user name in the login information.

Among them, privileged accounts often have special user names, such as root, admin, DBA, etc. If such a user name is detected, it indicates that the account is likely to be a privileged account. Of course, the privileged account can also be a user-defined privileged account username. Here, there may be multiple types of privileged accounts, which are not limited to the types listed in this embodiment. In addition, the privileged account may also be identified in other ways, which is not specifically limited in this embodiment of the present application.

S206: After performing weak password detection on the login information, if it is determined that there is a weak password in the login information, store the login information in a security log format in a preset security log table.

It should be noted that, in this embodiment of the present application, when it is determined that there is a weak password in the login information, the login information is stored in the preset security log table in a security log format. Here, the content stored in the preset security log table at least includes: a detected password with a weak password, and a user name corresponding to the password. In this way, the login information with weak passwords is stored in the preset security log table, which is convenient for the administrator to view, so as to rectify the accounts with weak passwords in time.

In some embodiments, after performing weak password detection on the login information, the method may further include:

If it is determined that there is a weak password in the login information, early warning information is sent; wherein, the early warning information is used to prompt the user that the login information has a risk of a weak password.

It should be noted that, in this embodiment of the present application, if it is detected that there is a weak password in the login information, an early warning message may be sent at this time to prompt the administrator or user that the login information has a risk of weak password, so that the administrator or user can change the password in time. Or take other safety measures.

Further, in some embodiments, when it is determined that the user name is a privileged account, the method may further include:

If it is detected that the password is a weak password, the user name and the password are marked in a preset security log table.

It should be noted that, in the embodiment of the present application, as mentioned above, the privileged account is an important account, and if there is a risk of weak passwords, it may bring greater harm. Therefore, when it is detected that an account is a privileged account and the corresponding password is a weak password, the privileged account is marked and displayed differently from other accounts when it is stored in the preset security log table. Here, it may be marked by adding a label, or may be marked by a highlight color, or may even be marked by different fonts or different font sizes, which are not specifically limited in this embodiment of the present application.

In this way, the embodiments of the present application can quickly discover the weak password risk of an important account in massive data, so as to formulate protective measures in a targeted manner. Specifically, the privileged accounts with weak passwords can be displayed on a separate page in the preset security log table, or the privileged accounts with weak passwords can be marked, highlighted, etc.; privileged accounts with weak passwords can also be displayed The user name is marked with parentheses as a privileged account, and correspondingly, parentheses may be added after the username of a common account with a weak password to mark a common account, which is not specifically limited in this embodiment.

Since the privileged account is more important, in some embodiments, when the user name is determined to be a privileged account, a reminder message may also be sent directly to the administrator, where the reminder message is used to inform the administrator that the privileged account has a weak password risk , so that the administrator can make timely rectification and better ensure account security.

The embodiment of the present application provides a weak password detection method, and the specific implementation process of the foregoing embodiment is described in detail through this embodiment. It can be seen from this that the login request information is identified by using the preset rules to determine the component information to be logged in. Based on the login feature rules corresponding to the component information to be logged in, the login information can be accurately extracted from the login request information, and only When the login is successful, the login information is recorded in the audit log table and the weak password detection is performed on the login information by using the preset detection strategy. At the same time, the offline detection also supports the identification of privileged accounts. In this way, accurate detection of weak passwords for different login components is realized, and the detection rate of weak passwords is improved.

In another embodiment of the present application, referring to FIG. 3 , it shows a schematic structural diagram of a weak password detection system provided by an embodiment of the present application. As shown in FIG. 3 , the weak password detection system may include four major processes, namely: an agent process 301 , a log processing process 302 , a database process 303 and an offline detection process 304 .

Among them, in the embodiment of the present application, the proxy process 301 is used to audit the login information, and the Snort rules are used to perform the login feature rule matching on the HTTP data. First, match the login feature rules in the request direction, and after matching the login feature rules, extract the username and password, and cache them on the current link. Then match in the response direction, obtain the login status, and determine whether the login is successful. At this time, the request direction and the response direction of a link can be associated, and information such as the user name, password, and whether the login is successful can be audited for the current login.

The log processing process 302 is mainly used to receive an audit log, and the audit log includes information such as a user name, a password, and a source IP address and a destination IP address. Weak password detection mainly uses username and password. The offline detection process will be started periodically to complete weak password detection.

The database process 303 is mainly used to store an audit log table and a security log table. The audit log table records the audit log of login information, and the security log table records the security log of the weak password detection result.

The offline detection process 304 mainly includes preprocessing and detection. Preprocessing means filtering audit logs to collect useful data for weak password detection. Detection is the analysis and detection of the collected data.

Here, the preset detection strategies may include two categories: built-in weak password detection strategies and predefined weak password detection strategies. Built-in weak password detection strategies include: built-in password length detection strategy, built-in character type detection strategy, and common component weak password dictionary matching detection strategies; predefined weak password detection strategies include preset password length detection strategy, preset character type detection strategy, and Preset weak password dictionary matching detection strategies, etc.

In addition, in this embodiment of the present application, offline detection may also support identification of privileged accounts such as root and admin.

The log processing process 302 is also used to receive the security log, after offline detection of the login information in the audit log table, when a weak password is detected, the detection result is adapted to the security log format, and recorded in the security log in the database process 303 in the table.

The workflow of each process of a weak password detection system provided by an embodiment of the present application will be described in detail below with reference to FIG. 3 .

As shown in FIG. 3, the proxy process 301 may correspond to steps S3011 to S3018, and the details are as follows:

S3011: Obtain the request direction packet.

It should be noted that a weak password detection method provided by this embodiment of the present application can be implemented based on the HTTP (Hypertext Transfer) protocol during the user's login process. HTTP is a simple request-response protocol, which usually Runs on top of TCP. It specifies what kind of messages the client might send to the server and what kind of response it gets. In this embodiment of the present application, a login request is initiated in the request direction.

S3012: Determine whether the rule is hit.

Here, for step S302, if the judgment result is yes, then step S303 is executed; if the judgment result is no, then the login process is ended, and step S301 is executed again.

It should be noted that, in this embodiment of the present application, after the request direction packet is acquired, feature matching needs to be performed on the request direction packet information. Here, using the Snort engine, after first matching the login feature of the request direction message, the corresponding login feature rule can be determined, and the login component of this login request is also determined, and the login component includes the built-in common login Components, such as Joomla, EYOUCMS, DedeCMS, DouPHP, etc.; can also include user-defined login components, such as: internal business login system, private login components, etc. Among them, the common login component is an existing and commonly used login component; the custom login component may be a user-defined login component or a private login component only used in some enterprises.

In addition, common login components support online updates. For example, when a new login component appears, or a new login feature rule appears in the login component, that is, the online update includes the update of the login component and the login component feature rule, and the update may be regular or irregular, which is not made in this embodiment. Specific restrictions. The user-defined login component is mainly an internal or private login component of the user, and is mainly updated by the user actively. The update may also be regular or irregular, which is not specifically limited in this embodiment.

S3013: Extract the user name and password.

It should be noted that, in this embodiment of the present application, in step S302 , the log-in feature rule is determined after the request direction packet is matched with the rules, and the log-in feature rule can be accurately extracted from the request direction message according to different log-in feature rules. to username and password.

It should be noted that, directly extracting the login information, such as the user name and password, from the request direction packet may result in the login information not being extracted or the wrong login information being extracted. In the embodiment of the present application, since different login components have different login feature rules, the request direction packet can be first matched with the rules, and only after the rules are hit, the login component information is determined, and then based on the corresponding login component information The login feature rule extracts login information such as user name and password, which improves the accuracy of user name and password extraction.

It should be noted that there is a situation: if the Snort rule does not match the username and password, you need to try to parse the login parameters in Basic authentication mode, and match the result of Basic authentication as the login status. Basic authentication is an HTTP authentication method. The client base64 encodes the user name and password, and transmits it to the server through the Authorization header for authentication. That is to say, if the Basic authentication method is used, the user name and password may not be matched when the user name and password are extracted based on Snort rules, because Basic authentication will Base64 encode the user name and password. Decode, and perform login authentication based on the Basic authentication method.

S3014: Cache the user name and password.

It should be noted that, in this embodiment of the present application, after the user name and password are extracted, the user name and password may be cached on the current link. It is understandable that during the login process, there may be many users logging in at the same time, and the later data will overwrite the earlier data. In this embodiment, the login information needs to be audited, so the user name and password are first cached on the current link, so that the login information can be audited after the login status is confirmed later.

S3015: Obtain the response direction packet.

S3016: Detect the login status.

It should be noted that, in this embodiment of the present application, after the login user name and password are extracted in the request direction, feature matching is also required in the response direction to obtain the login status. The login status can be detected to determine whether the login is successful.

S3017: Determine whether the login is successful.

S3018: Generate an audit log.

It should be noted that, in this embodiment of the present application, if the correct username and password are extracted in the request direction, it means that the login can be successfully logged in, that is, the judgment result is yes, then step S3018 is executed; otherwise, it means that the login fails, that is, the judgment is made. If the result is no, then return to step S3011.

It should also be noted that when the login is successful, the login information is audited, and an audit log is generated, and the audit log includes the login information of the successful login. The login information may include: user name, password, and login status information. When the login fails, the login process is ended, and step S3011 is executed again.

It should be noted that there may be misjudgments in Snort feature matching. The solution here is that an audit needs to associate the request direction feature and the response direction feature. Only after the request direction matches the login user name and password, and then the response direction matches/detects the login status, and the audit is performed when both directions match. That is to say, there is a situation where it is detected that the user name and password or the user name and password are correct but no login is required or the response direction does not match, only when it is determined that the request direction has extracted the user name and password and the response direction determines that the login status is successful login, Only then will the detection result be recorded in the audit log table. In this way, only when the request direction and the response direction are matched successfully and the login status is determined to be successful, the login information will be audited, which improves the detection rate and reduces the pressure on the website.

As shown in FIG. 3 , the log processing process 302 may correspond to steps S3021 to S3022, and the details are as follows:

S3021: Receive logs.

S3022: Write to the database.

It should be noted that, in this step, the log processing process 302 is mainly used for writing the audit log. That is to say, when the proxy process 301 audits the successful login information, an audit log is generated, and the log processing process 302 receives the audit log and writes it into the database.

As shown in FIG. 3 , after receiving the audit log, the log processing process 302 stores the audit log in the audit log table in the database process 303 . Here, the database process 303 stores an audit log table and a security log table. The audit log table is used to record the login information of successful login, and the security log table is used to record the login information of the weak password.

It should be noted that, in the embodiment of the present application, the data for the offline detection process to detect comes from the audit log table audited by the agent process. When performing weak password detection, the offline detection process first reads the audit log table and obtains the login information recorded in the audit log table.

As shown in FIG. 3, after the offline detection process 304 reads the audit log table from the database process 303, the offline detection process 304 mainly includes the following steps:

S3041: Start the scheduled task.

S3042: Perform weak password detection.

S3043: Distribute the detection function according to the protocol.

It should be noted that, in this embodiment of the present application, the offline detection process will be started periodically to complete the weak password detection. For example, the detection is performed once an hour or once a day, which is not specifically limited in this embodiment. Offline detection can mainly include preprocessing and detection. Preprocessing is to filter the login information recorded in the audit log table, and collect useful data for weak password detection. Detection is the analysis and detection of the collected data. Among them, useful data mainly refers to user names and passwords, and detection usually refers to weak password detection, and mainly detects passwords.

It should also be noted that, in this embodiment of the present application, detection strategies for detecting passwords may include two types: built-in weak password detection strategies and predefined weak password detection strategies. The built-in weak password detection strategy can be preset by the system, and the predefined weak password detection strategy can be set by the user.

The built-in detection strategy may include: a built-in password length detection strategy, a built-in character type detection strategy, a weak password dictionary matching detection strategy for common components, and the like. The description of the implementation process is similar to that of the previous embodiment, and details are not repeated here.

The predefined weak password detection strategy may include: a preset password length detection strategy, a preset character type detection strategy, a preset weak password dictionary matching detection strategy, and the like. The description of the implementation process is similar to that of the previous embodiment, and details are not repeated here.

In this way, based on the preset detection strategy, weak password detection is performed on the password information that is successfully logged in. It should be noted that different protocols may need to use different detection functions during detection, so the detection functions need to be distributed according to the protocol. In the embodiment of the present application, it can be divided into other protocols and HTTP protocols; HTTP detection is performed; if other protocols are used, other protocol detection is performed, such as SMD protocol detection, RDP protocol detection, and the like.

In addition, offline detection can also support the identification of privileged accounts, such as the root account and the admin account. Because privileged accounts are different from ordinary accounts, they often have higher authority. If a privileged account has a weak password and is cracked, it will often bring more trouble and loss. In the offline detection process, when the weak password is detected, the privileged account will also be identified. The identification method can be: identifying the user name, the login name of the privileged account, such as root, admin, etc., and also including the privileged account specified by the user. In this way, if the offline detection identifies a user name that may be a privileged account, and the password corresponding to the user name is a weak password, the privileged account with the weak password will be marked in the security log or displayed separately, or in other ways with the Common accounts are distinguished, which is not specifically limited in this embodiment.

S3044: Generate a security log.

It should be noted that, in this embodiment of the present application, when a weak password is detected, a security log is generated according to the detection result. The security log may include the detected weak password and the corresponding user name. In addition, when a weak password is detected, the risk of weak password may also be reminded by means of an alarm, such as sending an alarm message to an administrator.

As shown in FIG. 3 , after receiving the security log, the log processing process 302 stores the security log in the security log table in the database process 303 .

That is, the database process module 303 includes at least an audit log table and a security log table, wherein the audit log recorded in the audit log table mainly includes login information of successful login, and the audit log is used to provide data to be detected for the offline detection process. The security logs recorded in the security log table mainly include login information with weak passwords, so that administrators can find hidden dangers of weak passwords in time and take corresponding measures when viewing the security logs.

The embodiment of the present application extracts the login feature rules for common login components with login interfaces, such as: Joomla, EYOUCMS, DedeCMS, DouPHP, etc., uses the Snort engine to perform rule matching on HTTP requests and responses, audits login information, and detects weak passwords. Accurate detection of weak password logins for different login components is achieved. At the same time, it supports scalability: the first feature rule base corresponding to common login components supports dynamic updating, and the second feature rule base corresponding to uncommon login components (such as internal business login systems, private login components, etc.) supports customization.

Through the above embodiments, the specific implementation of the above embodiments is described in detail. It can be seen that: this solution implements detection on the firewall, and there are a large number of Web systems in the firewall environment, and there are various login components. It can well protect the login system in the user's business. The first feature rule base built in this solution, which represents the feature rule base corresponding to common login components, supports online update. Different login components may have different login characteristics, and the components of the Web system are updated frequently. Online updates can reduce maintenance costs and rapidly improve detection capabilities. For unusual login components, this solution supports user-defined configuration of login feature rules, effectively covering the user's private business system scenarios and protecting the security of the user's intranet web system. This solution also supports the identification of privileged accounts, which can help users quickly discover weak password risks of important accounts in massive security logs, and formulate protective measures in a targeted manner.

For yet another embodiment of the present application, see FIG. 4 , which shows a schematic structural diagram of a weak password detection apparatus 40 provided by an embodiment of the present application. As shown in FIG. 4 , the weak password detection apparatus 40 may include: a receiving unit 401, a determining unit 402, an extracting unit 403 and a detecting unit 404; wherein,

A receiving unit 401, configured to receive login request information;

A determining unit 402, configured to determine a login feature rule corresponding to the login request information;

Extraction unit 403, configured to extract login information from the login request information based on the login feature rule;

The detection unit 404 is configured to perform weak password detection on the login information when it is detected that the login status is successful login, so as to determine whether there is a weak password in the login information.

In some embodiments, the determining unit 402 is further configured to identify the login request information by using a preset identification rule, and determine the component information to be logged in; and based on the component information to be logged in, determine from the preset rule base all The login feature rules corresponding to the component information to be logged in; wherein, the preset rule base includes multiple login component information and respective login feature rules corresponding to the multiple login component information.

In some embodiments, the determining unit 402 is further configured to perform feature matching between the component information to be logged in and the preset rule base; and determine the log-in feature rule from the preset rule base according to the matching result .

In some embodiments, the preset identification rules include Snort rules.

In some embodiments, the preset rule base further includes a first feature rule base and a second feature rule base; wherein the first feature rule base represents a feature rule base corresponding to common login components, and the second feature rule base The rule base represents the pre-configured feature rule base corresponding to the uncommon login components.

In some embodiments, referring to FIG. 5 , the weak password detection apparatus 40 may further include an update unit 405 configured to update the first feature rule base online.

In some embodiments, referring to FIG. 5 , the weak password detection apparatus 40 may further include a storage unit 406 configured to, if it is determined that there is a weak password in the login information, store the login information in a secure log format to a preset Set up a security log table.

In some embodiments, the storage unit 406 is further configured to write the login information into the audit log table when it is detected that the login status is a successful login;

The detection unit 404 is further configured to start an offline detection process; obtain the login information from the audit log table, and perform weak password detection on the login information by using a preset detection strategy.

In some embodiments, the login information includes a user name and a password, and the detection unit 404 is further configured to perform privileged account identification on the login information, and determine whether the user name is a privileged account.

In some embodiments, the detection unit 404 is further configured to, when it is determined that the user name is a privileged account, if it is detected that the password is a weak password, the user name and the password are stored in a preset security log table mark.

In some embodiments, the built-in weak password detection strategy includes at least one of the following: a built-in password length detection strategy, a built-in character type detection strategy, and a common component weak password dictionary matching detection strategy; the predefined weak password detection strategy at least It includes one of the following: a preset password length detection strategy, a preset character type detection strategy, and a preset weak password dictionary matching detection strategy.

In some embodiments, referring to FIG. 5 , the weak password detection apparatus 40 may further include an early warning unit 407 configured to send early warning information if it is determined that there is a weak password in the login information; wherein, the early warning information is used for The user is prompted that the login information has a weak password risk.

It can be understood that, in this embodiment, a "unit" may be a part of a circuit, a part of a processor, a part of a program or software, etc., of course, it may also be a module, and it may also be non-modular. Moreover, each component in this embodiment may be integrated into one processing unit, or each unit may exist physically alone, or two or more units may be integrated into one unit. The above-mentioned integrated units can be implemented in the form of hardware, or can be implemented in the form of software function modules.

If the integrated unit is implemented in the form of a software functional module and is not 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 embodiment is essentially or The part that contributes to the prior art or the whole or part of the technical solution can be embodied in the form of a software product, the computer software product is stored in a storage medium, and includes several instructions for making a computer device (which can be It is a personal computer, a server, or a network device, etc.) or a processor (processor) that executes all or part of the steps of the method described in this embodiment. The aforementioned storage medium includes: U disk, removable hard disk, Read Only Memory (ROM), Random Access Memory (Random Access Memory, RAM), magnetic disk or optical disk and other media that can store program codes.

Therefore, this embodiment provides a computer storage medium, where the computer storage medium stores a weak password detection program, and when the weak password detection program is executed by at least one processor, implements the method described in any one of the foregoing embodiments. step.

Based on the above-mentioned composition of a weak password detection apparatus 40 and a computer storage medium, see FIG. 6 , which shows a schematic diagram of a specific hardware structure of a weak password detection apparatus 40 provided by an embodiment of the present application. As shown in FIG. 6 , it may include: a communication interface 501 , a memory 502 and a processor 503 ; various components are coupled together through a bus system 504 . It will be appreciated that the bus system 504 is used to implement the connection communication between these components. In addition to the data bus, the bus system 504 also includes a power bus, a control bus, and a status signal bus. However, for clarity of illustration, the various buses are labeled as bus system 504 in FIG. 6 . Among them, the communication interface 501 is used for receiving and sending signals in the process of sending and receiving information with other external network elements;

a memory 502 for storing computer programs that can be executed on the processor 503;

The processor 503 is configured to, when running the computer program, execute:

Receive login request information;

determining the login feature rule corresponding to the login request information;

extracting login information from the login request information based on the login feature rule;

When it is detected that the login status is successful login, weak password detection is performed on the login information to determine whether there is a weak password in the login information.

It can be understood that the memory 502 in this embodiment of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memory. Wherein, the non-volatile memory may be Read-Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (Erasable PROM, EPROM), Erase programmable read-only memory (Electrically EPROM, EEPROM) or flash memory. The volatile memory may be random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM, SDRAM), double data rate synchronous dynamic random access memory (Double Data Rate SDRAM, DDRSDRAM), enhanced synchronous dynamic random access memory (Enhanced SDRAM, ESDRAM), synchronous link dynamic random access memory (Synchronous link DRAM, SLDRAM) And direct memory bus random access memory (Direct Rambus RAM, DRRAM). The memory 502 of the systems and methods described herein is intended to include, but not be limited to, these and any other suitable types of memory.

The processor 503 may be an integrated circuit chip, which has signal processing capability. In the implementation process, each step of the above-mentioned method can be completed by an integrated logic circuit of hardware in the processor 503 or an instruction in the form of software. The above-mentioned processor 503 may be a general-purpose processor, a digital signal processor (Digital Signal Processor, DSP), an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), a field programmable gate array (Field Programmable Gate Array, FPGA) or other Programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. The methods, steps, and logic block diagrams disclosed in the embodiments of this application can be implemented or executed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method disclosed in conjunction with the embodiments of the present application may be directly embodied as executed by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules may be located in random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, registers and other storage media mature in the art. The storage medium is located in the memory 502, and the processor 503 reads the information in the memory 502, and completes the steps of the above method in combination with its hardware.

It will be appreciated that the embodiments described herein may be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit may be implemented in one or more Application Specific Integrated Circuits (ASIC), Digital Signal Processing (DSP), Digital Signal Processing Device (DSP Device, DSPD), programmable logic Devices (Programmable Logic Device, PLD), Field-Programmable Gate Array (Field-Programmable Gate Array, FPGA), general purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described in this application or a combination thereof.

For a software implementation, the techniques described herein may be implemented through modules (eg, procedures, functions, etc.) that perform the functions described herein. Software codes may be stored in memory and executed by a processor. The memory can be implemented in the processor or external to the processor.

Optionally, as another embodiment, the processor 503 is further configured to execute the steps of the method in any one of the foregoing embodiments when running the computer program.

Based on the composition and hardware structure diagram of the weak password detection apparatus 40 described above, referring to FIG. 7 , it shows a composition structure diagram of a detection device 60 provided by an embodiment of the present application. As shown in FIG. 7 , the detection device 60 includes at least the weak password detection device 40 described in any one of the foregoing embodiments.

For the detection device 60, after receiving the login request information, by determining the login feature rules corresponding to the login request information, the feature rules corresponding to different login components can be accurately identified, and the login information to be detected can be accurately extracted, and further When weak password detection is performed on the login information, weak passwords under various login components can be accurately identified, the detection rate of weak passwords is improved, and the misjudgment rate of weak passwords is reduced.

The above descriptions are only preferred embodiments of the present application, and are not intended to limit the protection scope of the present application.

It should be noted that, in this application, the terms "comprising", "comprising" or any other variation thereof are intended to encompass non-exclusive inclusion, such that a process, method, article or device comprising a series of elements includes not only those elements , but also other elements not expressly listed or inherent to such a process, method, article or apparatus. Without further limitation, an element qualified by the phrase "comprising a..." does not preclude the presence of additional identical elements in a process, method, article or apparatus that includes the element.

The above-mentioned serial numbers of the embodiments of the present application are only for description, and do not represent the advantages or disadvantages of the embodiments.

The methods disclosed in the several method embodiments provided in this application can be arbitrarily combined under the condition of no conflict to obtain new method embodiments.

The features disclosed in the several product embodiments provided in this application can be combined arbitrarily without conflict to obtain a new product embodiment.

The features disclosed in several method or device embodiments provided in this application can be combined arbitrarily without conflict to obtain new method embodiments or device embodiments.

The above are only specific embodiments of the present application, but the protection scope of the present application is not limited to this. should be covered within the scope of protection of this application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims (15)

1. a weak password detection method, is characterized in that, described method comprises: Receive login request information; determining the login feature rule corresponding to the login request information; extracting login information from the login request information based on the login feature rule; When it is detected that the login status is successful login, weak password detection is performed on the login information to determine whether there is a weak password in the login information. 2. The method according to claim 1, wherein the determining the login feature rule corresponding to the login request information comprises: Identify the login request information by using a preset identification rule, and determine the component information to be logged in; Based on the to-be-registered component information, the login feature rule corresponding to the to-be-registered component information is determined from a preset rule base; wherein the preset rule base includes multiple types of login component information and the multiple types of login components The corresponding login feature rules for each message. 3 . The method according to claim 2 , wherein determining the log-in feature rule corresponding to the to-be-login component information from a preset rule base based on the to-be-login component information comprises: 3 . performing feature matching between the component information to be logged in and the preset rule base; According to the matching result, the login feature rule is determined from the preset rule base. 4. The method according to claim 2, wherein the preset identification rules comprise Snort rules. 5. The method according to claim 2, wherein the preset rule base comprises a first feature rule base and a second feature rule base; wherein the first feature rule base represents a feature corresponding to a common login component A rule base, where the second feature rule base represents a predefined configuration feature rule base corresponding to the uncommon login component. 6. The method according to claim 5, wherein the method further comprises: The first feature rule base is updated online. 7. The method according to claim 1, wherein after the weak password detection is performed on the login information, the method further comprises: If it is determined that there is a weak password in the login information, the login information is stored in a security log format in a preset security log table. 8. The method according to claim 1, characterized in that, in the case where it is detected that the login status is successful login, the method further comprises: writing the login information into the audit log table; Correspondingly, performing weak password detection on the login information includes: Start the offline detection process; The login information is obtained from the audit log table, and weak password detection is performed on the login information by using a preset detection strategy. 9. The method according to claim 8, wherein the login information includes a user name and a password, and after acquiring the login information from the audit log table, the method further comprises: Perform privileged account identification on the login information to determine whether the user name is a privileged account. 10. The method according to claim 9, wherein when it is determined that the user name is a privileged account, the method further comprises: If it is detected that the password is a weak password, the user name and the password are marked in a preset security log table. 11. The method according to claim 8, wherein the preset detection strategy comprises a built-in weak password detection strategy and a predefined weak password detection strategy; wherein, The built-in weak password detection strategy includes at least one of the following: a built-in password length detection strategy, a built-in character type detection strategy, and a common component weak password dictionary matching detection strategy; The predefined weak password detection strategy includes at least one of the following: a preset password length detection strategy, a preset character type detection strategy, and a preset weak password dictionary matching detection strategy. 12. A weak password detection device, characterized in that the weak password detection device comprises: a receiving unit, a determining unit, an extracting unit and a detecting unit; wherein the receiving unit, configured to receive login request information; The determining unit is configured to determine the login feature rule corresponding to the login request information; The extraction unit is configured to extract login information from the login request information based on the login feature rule; The detection unit is configured to perform weak password detection on the login information when it is detected that the login status is successful login, so as to determine whether there is a weak password in the login information. 13. A weak password detection device, characterized in that, the weak password detection device comprises: a memory and a processor; wherein, the memory for storing a computer program executable on the processor; The processor is configured to execute the weak password detection method according to any one of claims 1 to 11 when running the computer program. 14. A computer storage medium, characterized in that the computer storage medium stores a weak password detection program, and when the weak password detection program is executed by at least one processor, the method according to any one of claims 1 to 11 is implemented. Weak password detection method. 15. A detection device, characterized in that, the detection device at least comprises the weak password detection device according to claim 12 or 13.

Images