A weak password detection method and device, electronic equipment and storage medium

Abstract

The specification provides a weak password detection method and device, electronic equipment and storage medium, the method comprises: determining a target service to be detected, and obtaining a weak password dictionary; in turn attempt to use each weak password combination in the weak password dictionary to log in the target service, wherein, attempting to use any weak password combination to log in the target service comprises: initiating a login request containing the any weak password combination to the target service, and receiving response information for the login request; in the case that the response information indicates that the login request party is locked, extracting the lock duration in the response information, wherein the login request party is unlocked after the lock duration arrives; and if there is a next weak password combination in the weak password dictionary that has not been attempted to log in, then after waiting for the lock duration, initiate a login request containing the next weak password combination to the target service.

Description

Technical Field

[0001] This specification relates to the field of network security technology, and in particular to a weak password detection method, device, electronic device, and storage medium. Background Technology

[0002] With the widespread use of internet applications, network security has become a major concern. Among these concerns, the security of account passwords is paramount. However, many users lack security awareness and set overly simple passwords, making them vulnerable to hacker attacks and resulting in serious consequences such as account theft and data breaches.

[0003] For the above scenario, security professionals can record easily cracked passwords (i.e., weak passwords) in a list and try to probe the service's password using each weak password in turn. If the probe is successful, it indicates that the service's password has a security risk and needs to be reset with a more complex password to improve security. However, for services that limit the number of failed login attempts, the requester will be locked out after reaching the limit. During the lockout period, regardless of whether the password is correct or not, the requester cannot log in to the service. Since different services have different parameter values ​​for the login failure limit and lockout duration, an adaptive weak password detection strategy is needed to adapt to the uncertainty of these parameter values, thereby improving the versatility of the solution. Summary of the Invention

[0004] To overcome the problems existing in related technologies, this specification provides a weak password detection method, device, electronic device, and storage medium.

[0005] According to a first aspect of the embodiments of this specification, a weak password detection method is provided, the method comprising:

[0006] Identify the target service to be probed and obtain a weak password dictionary, wherein the weak password dictionary includes multiple weak password combinations, and any weak password combination includes a username and a weak password.

[0007] Try logging into the target service using each weak password combination from the weak password dictionary in sequence, wherein trying to log into the target service using any weak password combination includes:

[0008] Initiate a login request to the target service containing any of the weak password combinations, and receive response information for the login request;

[0009] If the response information indicates that the login requester is locked, the lock duration in the response information is extracted, wherein the login requester is unlocked after the lock duration expires; and if there is a next weak password combination in the weak password dictionary that has not yet been attempted to log in, then after waiting for the lock duration, a login request containing the next weak password combination is sent to the target service.

[0010] According to a second aspect of the embodiments of this specification, a weak password detection device is provided, the device comprising:

[0011] The preparation module is used to determine the target service to be probed and obtain a weak password dictionary, wherein the weak password dictionary includes multiple weak password combinations, and any weak password combination includes a username and a weak password.

[0012] The detection module is configured to sequentially attempt to log in to the target service using each weak password combination in the weak password dictionary. Attempting to log in to the target service using any weak password combination includes: initiating a login request to the target service containing the chosen weak password combination, and receiving a response to the login request; if the response indicates that the login requester is locked, extracting the lock duration from the response, wherein the login requester is unlocked after the lock duration expires; and if there is a next weak password combination in the weak password dictionary that has not yet been attempted to log in, then waiting for the lock duration before initiating a login request to the target service containing the next weak password combination.

[0013] According to a third aspect of the embodiments of this specification, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in the first aspect.

[0014] According to a fourth aspect of the embodiments of this specification, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method described in the first aspect.

[0015] The technical solutions provided in the embodiments of this specification may include the following beneficial effects:

[0016] For the target service to be probed, during the process of sequentially attempting to log in using multiple weak password combinations recorded in the weak password dictionary, the response information of the target service to the login request can be parsed to determine whether the current login requester is locked. If the current login requester is locked, the waiting time required to unlock it is determined, and after the waiting time, a login request containing the next weak password combination is sent to the target service. Through the embodiments of this specification, when probing weak passwords for a target service, the parsing of the obtained response information can accurately determine whether the login requester is locked, and after it is locked, wait for an accurate waiting time before retrying the login. It can be seen that this solution can flexibly adjust the waiting time in the weak password probing strategy to cope with the uncertainty of the waiting time parameter value for different services, thereby effectively improving the versatility of the weak password probing strategy of this solution.

[0017] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this specification. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this specification and, together with the description, serve to explain the principles of this specification.

[0019] Figure 1 This is a flowchart illustrating a weak password detection method according to an exemplary embodiment of this specification.

[0020] Figure 2 This is a flowchart illustrating the determination of the lockout state of a login requester according to an exemplary embodiment of this specification.

[0021] Figure 3 This is a flowchart illustrating another weak password detection method according to an exemplary embodiment of this specification.

[0022] Figure 4 This is a schematic diagram of the structure of an electronic device according to an exemplary embodiment.

[0023] Figure 5 This is a block diagram illustrating a weak password detection device according to an exemplary embodiment of this specification. Detailed Implementation

[0024] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this specification as detailed in the appended claims.

[0025] The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of this specification. The singular forms “a,” “the,” and “the” as used in this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0026] It should be understood that although the terms first, second, third, etc., may be used in this specification to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this specification, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0027] With the widespread use of internet applications, network security has become a major concern. Among these concerns, the security of account passwords is paramount. However, many users lack security awareness and set overly simple passwords, making them vulnerable to hacker attacks and resulting in serious consequences such as account theft and data breaches.

[0028] To address the above scenario, security professionals can record easily cracked passwords (i.e., weak passwords) in a list and then attempt to probe the service's password using each weak password in turn. If the probe is successful, it indicates that the service's password has a security risk and needs to be reset with a more complex password to improve security. However, for services that limit the number of failed login attempts, once the login requester reaches the limit, the requester will be locked out. During the lockout period, regardless of whether the password is correct or not, the user cannot log in to the service.

[0029] Because different services have different login parameter values ​​for the number of failed login attempts and the lockout duration, the general practice is to manually set the number of weak passwords and the lockout duration for each round of probes before the probe begins, and then follow the preset probe parameter values ​​to probe for weak passwords on the service. However, if the above probe parameter values ​​are set incorrectly, the expected probe results will not be produced. For example, if the number of weak passwords set for each round of probes is greater than the actual number of failed login attempts of the target service, the login requester may still attempt to log in to the target service using weak passwords while the login requester is locked out. Even if the above probe parameter values ​​are set correctly, it is difficult to flexibly adapt to the ever-changing probe process. For example, if the probed service has enabled the function of limiting N failed login attempts, after the Nth successful login, the probed service will clear the previous N-1 failed login records, so it can actually continue to try to log in at least N more times. However, since the number of weak passwords for each round of probes has been set to a fixed value, after the Nth successful login, it is necessary to wait for the set lockout duration before it can try to log in again, which wastes testing time.

[0030] To address the aforementioned issues, this specification proposes a weak password detection method to improve the versatility of the weak password detection strategy in this solution.

[0031] Next, combine Figure 1 The embodiments described in this specification are explained in detail.

[0032] like Figure 1 As shown, Figure 1 This is a flowchart illustrating a weak password detection method according to an exemplary embodiment, comprising the following steps:

[0033] Step 101: Identify the target service to be probed and obtain a weak password dictionary.

[0034] In one embodiment, the target service to be probed can be software or a program running on a server, providing specific functions. These services can be network services, application services, or database services, etc. The target service to be probed can also be software or a program installed on a smartphone, smart TV, IoT device, or medical device, etc. Of course, the above are merely illustrative examples, and this specification does not impose any limitations on the device to be probed or the types of services on the device to be probed.

[0035] In one embodiment, weak password detection can be initiated against a target service on the target device. In this embodiment, it is not necessary to consider whether the target service being detected is running.

[0036] However, there is a special case in the above embodiments: if weak password detection is performed on services that are closed or unavailable, the expected detection results will not be obtained.

[0037] Therefore, preferably, before detection, it can be determined whether the target service to be detected is in an open state, and only target services that are in an open state are detected. Specifically, before detection, it is possible to identify the open services on the device to be detected that can provide services normally to the outside world, and then filter out the target service to be detected from the open services to ensure that the target service to be detected is currently providing services normally to the outside world. For example, the names of all open services on the device to be detected can be matched with the name of the target service to be detected, and the open services that match successfully can be used as the target service to be detected. In this embodiment, by filtering out the target service from all open services on the device to be detected, services that are closed or in an abnormal state can be excluded, and efforts can be focused on available services to obtain reliable detection results.

[0038] In one embodiment, this specification describes a method for determining an enabled service: First, the network connectivity of the IP address of the device to be probed can be tested. If the network of the IP address of the device to be probed is not connected, it indicates that the IP address is not active. Any request information sent to the target service on the device with the not active IP address will not reach it, thus preventing the detection of weak passwords for any service on the probe device. If the detection result shows that the network of the IP address of the device to be probed is connected, it indicates that the IP address is active. It should be noted that since a device to be probed may include at least one IP address, the number of active IP addresses can also be multiple. Provided that connectivity with at least one active IP address of the device to be probed is maintained, the open valid port number of the device to be probed is obtained, and the service corresponding to the valid port number is determined as an enabled service.

[0039] Of course, besides the methods described above for determining the running status of a target service, alternatively, a request can be sent to the target service on the device to be probed to attempt communication. If a response is successfully received from the target service, it indicates that the target service is running. Otherwise, the target service is shut down or unavailable.

[0040] In one embodiment, the weak password dictionary can be a list of common or simple usernames and passwords. For example, "123456" is a common password. The collected usernames and passwords can be used to generate multiple weak password combinations through a Cartesian product, where each weak password combination includes a username and a password. For example, if M usernames and N passwords are collected, they can be combined into M*N different weak password combinations. Alternatively, the original username and password pairings can be used directly as weak password combinations without disrupting the original mapping. This specification does not impose any restrictions on the method of generating the weak password dictionary.

[0041] In one embodiment, a general weak password dictionary can be applied to the detection tasks of multiple different services. For example, a general weak password dictionary A can be applied to services to be detected 1, services to be detected 2, ..., services to be detected N, etc. However, since different types of services may have different password policies, a specific weak password dictionary can be set for the password policy of the service to be detected. For example, a specific weak password dictionary A can be set for service to be detected 1, and a specific weak password dictionary B can be set for service to be detected 2. Of course, services to be detected with similar password policies can also be grouped together, and a corresponding group weak password dictionary can be set for a certain group of services to be detected, wherein the detection service group can contain different types of services. For example, a corresponding group weak password dictionary can be set for a group of services to be detected composed of different services to be detected 1 and 2.

[0042] Step 102: Send a login request containing a weak password combination to the target service and receive the response information for the login request.

[0043] Step 103: Determine if the weak password dictionary contains a next weak password combination that has not yet been attempted to log in.

[0044] To test how many weak password combinations in the weak password dictionary can successfully log in to the target service, it is necessary to try logging in to the target service using each weak password combination in the weak password dictionary in turn. For example, if the weak password dictionary contains N weak password combinations, it is necessary to traverse the weak password dictionary N times and send N login requests to the target service containing any of the weak password combinations.

[0045] Each time a response to a login request is received, it can be determined whether the response indicates that the login requester has successfully logged in:

[0046] If the response indicates that the login requester has successfully logged in, and the weak password dictionary contains a next weak password combination that has not yet been used, then a login request containing that next weak password combination can be sent to the target service. For example, if the response message contains an access token or session token, then the login request has been successful.

[0047] If the response indicates that the login requester failed to log in, and there is a weak password combination in the weak password dictionary that has not yet been logged in, then proceed to step 104.

[0048] If the weak password combination used in this login request is the last weak password combination in the weak password dictionary, it means that there are no remaining weak password combinations for detection, and the current detection can end.

[0049] Step 104: Determine whether the response information indicates that the login requester is locked.

[0050] Step 105: Extract the lock duration from the response information, and after waiting for the lock duration, send a login request containing the next weak password combination to the target service.

[0051] When a login requester repeatedly attempts to log in to a service using invalid credentials, and the number of failed login attempts reaches a certain threshold, the service will temporarily block the login requester from continuing to log in. This means that regardless of whether the provided credentials are correct, the login requester cannot log in again; in other words, the login requester is locked out. Therefore, during the lockout period, if the login requester continues to attempt to log in to the target service, the expected probe results may not be obtained because the login status cannot be accurately determined from the response information.

[0052] Therefore, after step 104 determines that the response information indicates that the login requester is not locked, it means that the login requester can continue to try to log in. Then, the process can jump to step 102 and send a login request containing the next weak password combination to the target service.

[0053] After determining in step 104 that the response information indicates that the login requester is locked, step 105 is executed, and the lock duration is extracted from the response information. After waiting for the lock duration, a login request containing the next weak password combination is sent to the target service.

[0054] In the above steps, since the locking status and locking duration of the login requester are determined based on the response information returned by the target service each time, it is possible to accurately determine whether the login requester is locked. Furthermore, if the login requester is accurately locked, the locking duration can be extracted from the response information to ensure that the waiting time is consistent with the actual locking duration, thus avoiding sending the next login request too early or too late and avoiding the risks caused by misjudging the locking status and locking duration.

[0055] like Figure 2 As shown, this specification provides a method for determining whether a login requester is locked by responding to the response information:

[0056] Step 201: Obtain the regular expression corresponding to the identity information of the target service.

[0057] Regular expressions are expressions used to describe string patterns. They consist of characters and special metacharacters. By using different metacharacters and syntax rules, strings that match specific patterns can be matched. Therefore, for various services that need to be probed, we can collect the response information output when certain failure conditions are met, and design corresponding regular expressions by parsing the string structure in the response information so that the regular expression can uniquely match the response information. Different regular expressions can be designed for different services, and the identity information used to uniquely identify the service can be associated and stored with the corresponding regular expression. This way, after determining the identity information of the target service, the corresponding regular expression can be determined.

[0058] In one embodiment, the identity information of the target service can be the name of the target service, or it can be the name of the target service and its version number. If the identity information of the target service includes the version number, different versions of the same service can be distinguished more precisely. Even if the failure conditions and lock duration parameters of different versions of the service change, the regular expression corresponding to the target service of that version can be found through the version number.

[0059] The identity information of the target service can be obtained in step 101. For example, specialized scanning tools such as Nmap or OpenVAS can be used to scan the target service and obtain its name and version number. Alternatively, the target service's identity information can be obtained in other ways, such as by sending a request to the target service and parsing the relevant fields in the HTTP header of the response message returned by the target service to determine the target service's name and version number. This specification does not limit the methods used to obtain the target service's identity information.

[0060] Step 202: If the response information matches the regular expression, determine that the response information indicates that the login requester is locked.

[0061] If the string structure and / or string content of the response message matches a regular expression, it can be determined that the response message indicates the login requester is locked. For example, if the response message contains the string "Too many login failures, your account has been locked," indicating that the login requester is locked, it can be matched against the response message using the corresponding regular expression "locked|account locked|login failed\s*times\s*too\s*,?\s*your\s*account\s*locked\s*". If the match is successful, it is determined that the response message indicates the login requester is locked; otherwise, it is determined that the response message indicates the login requester is not locked.

[0062] The code logic for steps 201 and 202 can be written into a regular expression-based login lockout engine. This engine automates the process of determining the login requester's lockout status. The engine can be associated with a regular expression library that stores service identity information and corresponding regular expressions. Different regular expressions can successfully match the response information of different services, indicating that the login requester is locked. By inputting the service's identity information and the received response information into the engine, the engine can determine the corresponding regular expression based on the service's identity information and automatically match the response information to determine whether the response indicates the login requester is locked.

[0063] In addition, this regular expression-based login lock engine can also extract the lock duration from the response information when the login requester is locked.

[0064] In another embodiment, the response information may also include a lock flag field, the value of which can be used to indicate whether the login requester is locked. For example, a value of 1 indicates that the login requester is locked, and a value of 0 indicates that the login requester is not locked. In this case, the login requester can directly extract the value of this field from the response information to determine whether the login requester is locked. Compared to the aforementioned embodiment that uses regular expression matching to determine whether the login requester is locked, this method eliminates the need for the login requester to perform complex judgments on the obtained response information. The logic for determining whether the login requester is locked is simple and efficient, which helps improve detection efficiency.

[0065] This concludes the explanation of the aforementioned weak password detection methods. Figure 3 As shown in the figure, this manual also provides another method for detecting weak passwords, which will be explained in detail below with relevant steps.

[0066] In step 301, the live IP address of the device to be detected and its open valid port number are determined, and the service provided by the valid port number is determined to be an enabled service.

[0067] In step 302, the target service to be detected is selected from the enabled services to ensure that the target service is enabled.

[0068] In step 303, a weak password dictionary corresponding to the target service is obtained.

[0069] In step 304, the system sequentially attempts to send login requests containing weak password combinations to the target service using each weak password combination from the weak password dictionary, and receives response information for the login requests.

[0070] In step 305, the system determines whether the login requester has successfully logged in based on the response information. If the login is successful, proceed to step 306; otherwise, continue to step 308.

[0071] In step 306, the weak password combinations that were successfully logged in are recorded. After all weak password combinations have been checked, a prompt message can be sent to the account corresponding to all successfully logged-in weak password combinations to remind the user to change to a stronger password in time.

[0072] In step 307, it is determined whether there is a weak password combination in the weak password dictionary that has not yet been attempted to log in. If it exists, the process jumps to step 304 to continue the detection; otherwise, the current detection task ends.

[0073] In step 308, it is determined whether the weak password dictionary contains a next weak password combination that has not yet been attempted to log in. If the weak password dictionary contains a next weak password combination that has not yet been attempted to log in, then proceed to step 309; otherwise, end the current detection task.

[0074] In step 309, the identity information and response information of the target service are input into the regular expression recognition login locking engine, so that the regular expression recognition login locking engine can determine whether the response information indicates that the login requester is locked.

[0075] In step 310, the login locking engine uses regular expressions to determine whether the login requester is locked. If so, proceed to step 311; otherwise, jump to step 304.

[0076] In step 311, the lock duration is extracted from the response information, and after waiting for the lock duration, a login request containing the next weak password combination is sent to the target service.

[0077] Corresponding to the embodiments of the foregoing methods, this specification also provides embodiments of the apparatus and the terminal to which it is applied.

[0078] like Figure 4 As shown, Figure 4 This is a schematic diagram illustrating the structure of an electronic device according to an exemplary embodiment of this specification. At the hardware level, the device includes a processor 402, an internal bus 404, a network interface 406, memory 408, and non-volatile memory 410, and may also include other hardware required for various services. One or more embodiments of this specification can be implemented in software, for example, the processor 402 reads the corresponding computer program from the non-volatile memory 410 into memory 408 and then runs it. Of course, besides software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution entity of the following processing flow is not limited to individual logic modules, but can also be hardware or logic devices.

[0079] like Figure 5 As shown, Figure 5 This is a block diagram illustrating a weak password detection device according to an exemplary embodiment. The device can be applied to, for example... Figure 4 The electronic device shown implements the technical solution of this specification. The device includes:

[0080] The preparation module 502 is used to determine the target service to be probed and obtain a weak password dictionary, wherein the weak password dictionary includes multiple weak password combinations, and any weak password combination includes a username and a weak password.

[0081] The detection module 504 is configured to sequentially attempt to log in to the target service using each weak password combination in the weak password dictionary. Attempting to log in to the target service using any weak password combination includes: initiating a login request to the target service containing the any weak password combination, and receiving response information for the login request; if the response information indicates that the login requester is locked, extracting the lock duration from the response information, wherein the login requester is unlocked after the lock duration expires; and if there is a next weak password combination in the weak password dictionary that has not yet been attempted to log in, then waiting for the lock duration before initiating a login request to the target service containing the next weak password combination.

[0082] Optionally, the preparation module 502 is specifically used to determine the enabled services that are in an enabled state, and to filter the target service to be detected from the enabled services.

[0083] Optionally, the preparation module 502 is specifically used to determine the live IP address of the device to be detected and its open valid port number, and to determine the service provided by the valid port number as the enabled service.

[0084] Optionally, different target services have their own specific weak password dictionaries, and the preparation module 502 is specifically used to obtain the specific weak password dictionary corresponding to the target service.

[0085] Optionally, the detection module 504 is specifically used to obtain the regular expression corresponding to the identity information of the target service; if the response information matches the regular expression, it is determined that the response information indicates that the login requester is locked.

[0086] Optionally, the identity information of the target service includes: the name of the target service; or, the name and version number of the target service.

[0087] Optionally, it also includes a login success module (not shown in the figure), which is used to initiate a login request containing the next weak password combination to the target service if the response information indicates that the login requester has successfully logged in and the weak password dictionary contains a next weak password combination that has not yet been attempted to log in.

[0088] The specific implementation process of the functions and roles of each module in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0089] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of the solution in this specification according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0090] This specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the aforementioned weak password detection methods provided in this application.

[0091] Specifically, computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, such as semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD-ROM and DVD-ROM disks.

[0092] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0093] Other embodiments of this specification will readily occur to those skilled in the art upon consideration of the specification and practice of the invention claimed herein. This specification is intended to cover any variations, uses, or adaptations that follow the general principles of this specification and include common knowledge or customary techniques in the art not claimed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this specification are indicated by the following claims.

[0094] It should be understood that this specification is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this specification is limited only by the appended claims.

[0095] The above description is merely a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of protection of this specification.

Claims

1. A method for detecting weak passwords, characterized in that, The method includes: Identify the target service to be probed and obtain a weak password dictionary, wherein the weak password dictionary includes multiple weak password combinations, and any weak password combination includes a username and a weak password. Try logging into the target service using each weak password combination from the weak password dictionary in sequence. Specifically, trying to log into the target service using any weak password combination includes: Initiate a login request to the target service containing any of the weak password combinations, and receive response information for the login request; If the response information indicates that the login requester is locked, the lock duration in the response information is extracted, wherein the login requester is unlocked after the lock duration expires; and if there is a next weak password combination in the weak password dictionary that has not yet been attempted to log in, then after waiting for the lock duration, a login request containing the next weak password combination is sent to the target service.

2. The method according to claim 1, characterized in that, The service for determining the target to be detected includes: Identify the services that are currently enabled, and filter the target service to be detected from among the enabled services.

3. The method according to claim 2, characterized in that, The determination of enabled services in the enabled state includes: Determine the live IP address of the device to be detected and its open valid port number, and identify the service provided by the valid port number as the enabled service.

4. The method according to claim 1, characterized in that, Different target services have their own specific weak password dictionaries. Obtaining the weak password dictionary includes: Obtain a specific weak password dictionary corresponding to the target service.

5. The method according to claim 1, characterized in that, Determining that the response information indicates the login requester is locked includes: Obtain the regular expression corresponding to the identity information of the target service; If the response information matches the regular expression, it is determined that the response information indicates that the login requester is locked.

6. The method according to claim 5, characterized in that, The identity information of the target service includes: the name of the target service; or, the name and version number of the target service.

7. The method according to claim 1, characterized in that, The method further includes: If the response information indicates that the login requester has successfully logged in, and the weak password dictionary contains a next weak password combination that has not yet been attempted to log in, then a login request containing the next weak password combination is sent to the target service.

8. A weak password detection device, characterized in that, The device includes: The preparation module is used to determine the target service to be probed and obtain a weak password dictionary, wherein the weak password dictionary includes multiple weak password combinations, and any weak password combination includes a username and a weak password. The detection module is configured to sequentially attempt to log in to the target service using each weak password combination in the weak password dictionary. Attempting to log in to the target service using any weak password combination includes: initiating a login request to the target service containing the chosen weak password combination, and receiving a response to the login request; if the response indicates that the login requester is locked, extracting the lock duration from the response, wherein the login requester is unlocked after the lock duration expires; and if there is a next weak password combination in the weak password dictionary that has not yet been attempted to log in, then waiting for the lock duration before initiating a login request to the target service containing the next weak password combination.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.

Images