CN107959683B - User name locking method and server - Google Patents
User name locking method and server Download PDFInfo
- Publication number
- CN107959683B CN107959683B CN201711284991.0A CN201711284991A CN107959683B CN 107959683 B CN107959683 B CN 107959683B CN 201711284991 A CN201711284991 A CN 201711284991A CN 107959683 B CN107959683 B CN 107959683B
- Authority
- CN
- China
- Prior art keywords
- user name
- time
- request
- login
- preset
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
Abstract
The application discloses a user name locking method and a server, wherein no matter the user name of a target website which is tried to log in by a user is a registered user name or an unregistered user name, the same processing method is adopted as long as the login cannot be realized, namely whether the user name meets a preset locking condition or not is determined, if the preset locking condition is met, the user name is locked, and if the preset locking condition is not met, prompt information is output. Therefore, the same processing mode is adopted for each user name which cannot realize login, so that a network attacker cannot identify whether the current user name is the registered user name, the identification difficulty of the registered user name is improved, and the network security is improved.
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to a user name locking method and a server.
Background
In the current network environment, a database collision attack belongs to a common attack mode, and the database collision attack is that a network attacker generates a corresponding dictionary table by collecting user name and password information which are leaked by the current internet, and tries to log in other websites in batches to obtain a series of users which can log in. Therefore, once the user sets the same user name and password in a plurality of websites for trouble saving, a network attacker can easily log in the websites through the information in the dictionary table, so as to obtain the relevant information of the user, such as the mobile phone number, the identification number, the home address, the payment treasure, the internet banking information and the like, and after the information is leaked, the information not only brings great loss to the spirit and the economy of the user, but also brings negative effects to the relevant websites. In addition, when a network attacker directly makes a large number of login requests reach the server through library collision attack, the pressure of the database of the server is increased sharply, and the database may be down, so that the whole login system fails.
In the existing verification mode of the user name and the password, when a user uses the user name and the password to request to log in a certain website, if the user name does not exist in a database at the server side, the server prompts that the user name does not exist; if the user name exists in the database of the server side, the user name and the password are further matched, and the user name is locked when the matching error times reach the preset times. However, this operation mode enables the network attacker to identify whether the user name is the registered user name, which provides convenience for the network attacker to implement the database collision attack and is not beneficial to network security.
Disclosure of Invention
The embodiment of the application mainly aims to provide a user name locking method and a server, which can improve the identification difficulty of registered user names and improve the network security.
The application provides a user name locking method, which comprises the following steps:
receiving a current login request for a target website, wherein the current login request carries a user name and a login password;
judging whether the user name is a registered user name or not;
if the user name is the registered user name, judging whether the user name is matched with the login password;
if the user name is not matched with the login password or the user name is not a registered user name, judging whether the user name meets a preset locking condition or not according to a current login request and a historical login request carrying the user name;
if the preset locking condition is met, locking the user name;
if the preset locking condition is not met, outputting prompt information, wherein the prompt information represents login failure and allows login again.
Optionally, the determining, according to the current login request and the historical login request carrying the user name, whether the user name meets a preset locking condition includes:
recording first request time, wherein the first request time is the request time corresponding to the current login request carrying the user name;
inquiring request time records corresponding to the user name, and determining the total number of records;
if the total number of records is equal to 1, determining that the user name does not meet a preset locking condition;
if the total number of records is greater than 1, calculating a time difference between the first request time and a second request time, wherein the second request time is the earliest request time recorded in the request time records;
if the time difference is greater than or equal to a preset time threshold, removing the second request time from the request time record, and determining that the user name does not meet a preset locking condition;
if the time difference is smaller than the preset time threshold, judging whether the total number of records is smaller than a preset time threshold; if so, determining that the user name does not meet the preset locking condition, and if not, determining that the user name meets the preset locking condition.
Optionally, the outputting the prompt information includes:
outputting the number of times that the user name can be requested to log in the target website;
the number of requestable times is a difference value between the preset time threshold and a time record value, and the time record value is a current record total number of the requested time records.
Optionally, the method further includes:
maintaining a time queue corresponding to the user name in a cache;
accordingly, the recording a first request time includes:
recording a first request time in the time queue;
accordingly, said removing the second request time from the request time record comprises:
removing the second request time from the time queue.
Optionally, the user name is a registered user name, and the method further includes:
receiving a registration request for the target website, wherein the registration request carries registration information, and the registration information comprises the user name and a registration password corresponding to the user name;
and synchronously writing the registration information into a database and a cache.
Optionally, the determining whether the user name is a registered user name includes:
querying a preset storage space, wherein the preset storage space is the database or the cache, and each registered user name of the target website and a registration password corresponding to the registered user name are stored in the preset storage space;
judging whether the user name is stored in the preset storage space or not;
if yes, determining that the user name is a registered user name, and if not, determining that the user name is not the registered user name;
correspondingly, the judging whether the user name is matched with the login password comprises:
inquiring the preset storage space, and acquiring a registration password corresponding to the user name;
judging whether the inquired registration password is the same as the login password or not;
if so, determining that the user name is matched with the login password, and if not, determining that the user name is not matched with the login password.
The present application further provides a server, comprising:
the system comprises a request receiving unit, a login processing unit and a login processing unit, wherein the request receiving unit is used for receiving a current login request for a target website, and the current login request carries a user name and a login password;
a user name judging unit, configured to judge whether the user name is a registered user name;
the password judgment unit is used for judging whether the user name is matched with the login password or not if the user name is the registered user name;
the locking judgment unit is used for judging whether the user name meets a preset locking condition according to a current login request and a historical login request carrying the user name if the user name is not matched with the login password or the user name is not a registered user name;
a user name locking unit, configured to lock the user name if the preset locking condition is met;
and the information prompting unit is used for outputting prompting information if the preset locking condition is not met, wherein the prompting information represents login failure and allows login again.
The present application further provides a server, including: a processor, a memory, a system bus;
the processor and the memory are connected through the system bus;
the memory is configured to store one or more programs, the one or more programs including instructions, which when executed by the processor, cause the processor to perform any of the above-described username locking methods.
The application also provides a computer-readable storage medium, in which instructions are stored, and when the instructions are run on a terminal device, the terminal device is caused to execute any implementation method of the user name locking method.
The application also provides a computer program product, and when the computer program product runs on the terminal device, the terminal device is enabled to execute any implementation method of the user name locking method.
The embodiment of the application provides a user name locking method and a server, and the method comprises the steps of firstly receiving a current login request for a target website, wherein the current login request carries a user name and a login password; if the user name is the registered user name, judging whether the user name is matched with the login password; if the user name is not matched with the login password or the user name is not a registered user name, judging whether the user name meets a preset locking condition or not according to a current login request and a historical login request carrying the user name. That is to say, no matter whether the user name is a registered user name or an unregistered user name, as long as login cannot be achieved, the same processing method is adopted, that is, whether the user name meets a preset locking condition is determined, if the preset locking condition is met, the user name is locked, and if the preset locking condition is not met, prompt information is output. Therefore, the same processing mode is adopted for each user name which cannot realize login, so that a network attacker cannot identify whether the current user name is the registered user name, the identification difficulty of the registered user name is improved, and the network security is improved.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, and it is obvious that the drawings in the following description are some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.
Fig. 1 is a flowchart of a username locking method according to a first embodiment of the present application;
FIG. 2 is a schematic diagram of a user login interface provided in the first embodiment of the present application;
fig. 3 is a flowchart of a username locking method according to a second embodiment of the present application;
FIG. 4a is a diagram of a time queue according to a second embodiment of the present application;
FIG. 4b is a second schematic diagram of a time queue according to the second embodiment of the present application;
FIG. 5 is a diagram illustrating a state transition of a time queue according to a second embodiment of the present application;
fig. 6 is a flowchart of a username locking method according to a third embodiment of the present application;
fig. 7 is a schematic composition diagram of a server according to a fourth embodiment of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some embodiments of the present application, but not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
First embodiment
Referring to fig. 1, the figure is a flowchart of a username locking method provided in this embodiment, and the username locking method provided in this embodiment includes the following steps:
s101: receiving a current login request for a target website, wherein the current login request carries a user name and a login password.
It should be noted that the username locking method provided in the following embodiments of the present application may be applied to a server. It should be further noted that, unless otherwise specified, the user mentioned in the following embodiments of the present application may be a legitimate user (simply, a legitimate user) of the target website, or may be a network attacker.
In addition, the present embodiment does not limit the type of the target website, for example, the target website may be a news website, a shopping website, a portal website, or the like.
As shown in fig. 2, when the user sends a login request to the server through the client, the user may input a user name and a login password in a login interface provided by the target website, and click a "login" button. After the user clicks the "login" button, the user may be considered that the login request of the target website has been successfully sent. At this time, the server may obtain a user name and a login password input by the user from the currently received login request.
S102: judging whether the user name is a registered user name or not; if yes, executing step S103; if not, step S104 is executed.
It can be understood that when a login request is initiated for a target website, on one hand, a valid user may input an error when inputting a user name, so that the currently input user name may be an unregistered user name; on the other hand, when a network attacker performs a library collision attack, the input user name is likely to be an unregistered user name.
S103: and judging whether the user name is matched with the login password, if not, executing the step S104, and if so, successfully logging in the target website.
It will be appreciated that when the username entered by the user is a registered username, the user will only be able to successfully log into the target website if the username matches the login password entered by the user.
S104: and judging whether the user name meets a preset locking condition or not according to the current login request and the historical login request carrying the user name, executing the step S105 if the user name meets the preset locking condition, and executing the step S106 if the user name does not meet the preset locking condition.
The historical login request mentioned in this embodiment refers to a login request for a target website sent by using the same user name before the current login request. For example, assuming that the user sends login requests to the target website once using the same user name at 5 different times of the day, namely 11:20, 11:23, 11:25, 11:29 and 11:30, if the sending time of the current login request is 11:30, the historical login request may include one or more of the login requests sent by the user to the target website at 11:20, 11:23, 11:25 and 11: 29.
The preset locking condition mentioned in the present embodiment is preset, and as an example, the preset locking condition may be: and sending a login request to the target website within a preset time threshold, wherein the times of unsuccessful login reach a preset time threshold. For example, the preset time threshold is 30 minutes, and the preset time threshold is 5 times, so that when the user sends a login request to a target website within 30 minutes and the number of times of unsuccessful login reaches 5 times, it is determined that the current user name meets the preset locking condition.
It can be understood that, when the user name input by the user is the registered user name, if the user name and the login password do not match, the user cannot log in successfully. When the user name input by the user is an unregistered user name, the user cannot log in successfully no matter what the login password input by the user is.
S105: and locking the user name.
It can be understood that, after the user name is locked, if the user name is continuously used to attempt to log in to the target website, even if the user name and the login password input by the user match, the login cannot be successful.
If the user name is locked, which is caused by the fact that the legal user forgets the user name or the behavior of a network attacker colliding with the library, the legal user of the user name cannot continuously use the user name to log in the target website, which is obviously unreasonable. Therefore, in this embodiment, S105 may specifically be: and locking the user name within a preset locking time, for example, the preset locking time is 6 hours, when the user name is locked within 6 hours, the user continues to use the user name to send a login request to a target website, the server does not perform login verification on the user name, but feeds back notification information of 'the user name is locked' to the user, and after 6 hours, the server recovers the login verification on the user name.
S106: and outputting prompt information, wherein the prompt information is information which represents that login fails and allows re-login.
It can be understood that when the user name does not meet the preset locking condition, the user name can still be used for sending a login request to the target website, and therefore, the prompt information is fed back to the user to prompt the user to retry login. For example, the prompt message may be: if the login fails, please re-input the user name and the login password.
The user name locking method provided by the embodiment includes the steps that a current login request for a target website is received, wherein the current login request carries a user name and a login password; if the user name is the registered user name, judging whether the user name is matched with the login password; if the user name is not matched with the login password or the user name is not a registered user name, judging whether the user name meets a preset locking condition or not according to a current login request and a historical login request carrying the user name. That is to say, no matter whether the user name is a registered user name or an unregistered user name, as long as login cannot be achieved, the same processing method is adopted, that is, whether the user name meets a preset locking condition is determined, if the preset locking condition is met, the user name is locked, and if the preset locking condition is not met, prompt information is output. Therefore, the same processing mode is adopted for each user name which cannot realize login, so that a network attacker cannot identify whether the current user name is the registered user name, the identification difficulty of the registered user name is improved, and the network security is improved.
Second embodiment
For the user name locking method provided in the first embodiment, a second embodiment will specifically describe an implementation method of S104 in the first embodiment with reference to the drawings.
Referring to fig. 3, the figure is a flowchart of a username locking method provided in this embodiment, and the username locking method provided in this embodiment includes the following steps:
s301: recording first request time, wherein the first request time is the request time corresponding to the current login request carrying the user name.
It should be noted that in the specific implementation of S301, a time queue may be maintained in a cache or other storage location for each user name that fails to pass the authentication, that is, a time queue may be created for a new user name only when the new user name is parsed from the login request and the new user name is an unregistered user name or the new user name is a registered user name but the login password is wrong.
For example, when a user A wants to log in a target website, if the user A tries to log in by using a user name A, the server inquires whether a time queue of the user name A exists; if the login request exists, directly recording the request time of the current login request carrying the user name A in the time queue; and if the login request does not exist, creating a new time queue for the user name A, and recording the request time of the current login request carrying the user name A in the time queue. Specifically, if the request time for user A to attempt login using username A is 11:30 and FIG. 4a is a time queue newly created for user A, the request time is recorded in the time queue as 11: 30; if the user A continues to request login with the user name A at 11:31 and the login fails, the requested time 11:31 is recorded in the time queue, as shown in FIG. 4 b. Further, if the user a tries to log in with the user name a after failing to log in for one or more times, and tries to log in with the user name B again, the request time is recorded according to the manner of the user name a, which is not described herein again.
Based on the above, the present embodiment may further include: maintaining a time queue corresponding to the user name in a cache; correspondingly, S301 may specifically include: a first request time is recorded in the time queue.
It should be noted that, for a time queue corresponding to any user name, all login requests corresponding to the time queue may be restricted from coming from the same source, for example, the login requests must come from the same IP address, and certainly, the login requests may not be restricted from coming from the same source, that is, the request time corresponding to any login request carrying the user name may be recorded in the time queue.
It should be noted that the size of the time queue is the same as the size of the preset number threshold, and the preset number threshold may refer to the relevant description in the following S306.
It can be understood that, each time a user sends a login request to a target website by using the same user name and the login is not successful, a request time record is added to a time queue corresponding to the user name. The order of recording the request times in the time queue is identical to the order of time in which the user sends a login request to the target site using the user name. For example, as shown in fig. 4b, when the user sends login requests to the target website once at 11:30 and 11:31 by using the same user name, two request time records of 11:30 and 11:31 are added in the time queue in sequence.
S302: and inquiring the request time record corresponding to the user name, and determining the total number of records.
For the time queue corresponding to the user name, the total number of time records existing in the time queue can be queried. For example, fig. 4a, the total number of time records is 1, and for example, fig. 4b, the total number of time records is 2.
S303: and judging whether the total number of records is greater than 1, if so, executing the step S304, and if not, executing the step S309.
It can be understood that, in order to avoid inconvenience to a valid user of the user name due to frequent locking of the user name, the user name is not locked when the user fails to log in the target website by using the user name for the first time. That is, when the total number of records is equal to 1, it may be directly determined that the current user name does not satisfy the preset lock condition. If the user fails to log in the target website by using the user name for multiple times, whether the user name needs to be locked needs to be further determined.
S304: calculating a time difference between the first request time and a second request time, the second request time being an earliest request time recorded in the request time record.
In step S304, a request time record may be queried from the time queue corresponding to the user name, and a time difference between a last request time record and a first request time record is calculated, where the last request time record is the first request time in step S301, that is, the request time corresponding to the current login request, and the first request time record is the second request time, that is, the earliest request time recorded in the time queue. For example, the time queue includes 3 request time records, where a first request time record is 11:25, a second request time record is 11:28, and a third request time record is 11:30, then the second request time is 11:25, the first request time is 11:30, and the time difference between the two is 5 minutes.
S305: and judging whether the time difference is smaller than a preset time threshold value, if so, executing step S306, and if not, executing step S308.
S306: and judging whether the total number of records is smaller than a preset number threshold, if so, executing step S309, and if not, executing step S307.
Regarding S305 and S306, if a login request is sent to a target website using the same user name within a preset time threshold and the number of times of unsuccessful login reaches a preset number threshold, the user name is locked. That is, the first request time is taken as a recording node, and within a preset time threshold before the first request time, if the user name is used to send a login request to a target website and the number of times of unsuccessful login reaches a preset number threshold, the user name is locked.
The preset time threshold is preset, and the preset time threshold is also preset. As an example, the preset time threshold may be 30 minutes, and the preset time threshold may be 5 times, and then within 30 minutes before the first request time, when the login request is sent to the target website by using the user name and the number of times of unsuccessful login reaches 5 times, the user name is locked.
It can be understood that, when the total number of time records of the same user name is equal to the preset number threshold, the time queue corresponding to the user name is in a filled state, and at this time, the user name satisfies the preset locking condition.
S307: and determining that the user name meets a preset locking condition.
S308: and removing the second request time from the request time record, and determining that the user name does not meet a preset locking condition.
It can be understood that, the determining whether the user name meets the lock condition is to determine whether the number of times that the login request is sent to the target website by using the user name and the login is not successful reaches a preset number of times threshold within a preset time threshold before the first request time, and when a time difference between the first request time and the second request time is greater than the preset time threshold, it indicates that the second request time is not within the preset time threshold, and at this time, the second request time should be removed from the request time record. For example, the preset time threshold is 30 minutes, the preset time threshold may be 5 times, the first request time is 11:30, the second request time is 10:50, and it is determined whether the user name meets the lock condition, whether the number of times that the user name is used to send a login request to the target website within 30 minutes before 11:30 (i.e., between 11:00 and 11: 30) and the login is unsuccessful reaches 5 times should be determined, and 10:50 is not between 11:00 and 11:30, at which time, the request time record corresponding to 10:50 should be deleted.
In this embodiment, S308 may specifically be: and removing the second request time from the time queue corresponding to the user name.
It is understood that, after the second request time is removed from the time queue, the total number of records in the time queue is the same as the total number of records corresponding to the first request time before the first request time is recorded (i.e., step S301), that is, after the oldest time record in the time queue is removed, the total number of records in the time queue is the same as the total number of records corresponding to the current request time before the current request record is added.
For example, referring to fig. 5, the queue length is 5, the total number of records in the time queue before the current login request is 4, the recorded request times are sequentially recorded in the time queue according to the time sequence, and the request times are respectively T1, T2, T3 and T4, wherein TI is earlier than T2, T2 is earlier than T3, and T3 is earlier than T4. If the request time corresponding to the current login request is T0, after removing the earliest time record T1, the recording position of each request time is shifted to the right, the total number of records in the time queue is 4, and at this time, the request times recorded in the time queue are T2, T3, T4, and T0, respectively.
That is, compared with before the first request time is recorded, after the second request time is removed in step S308, the total number of records in the time queue does not change, and before the first request time is recorded, the user name does not satisfy the preset locking condition, and after the second request time is removed, the user name still does not satisfy the preset locking condition.
S309: and determining that the user name does not meet a preset locking condition.
Regarding S308 and S309, after determining that the user name does not satisfy the preset locking condition, a prompt message may be further output, and specifically, the prompt message may include the number of requestable times for logging in to the target website using the user name. The number of requestable times is a difference value between the preset time threshold and a time record value, and the time record value is a current record total number of the requested time records.
Referring to fig. 5, after the current login request fails, the total number of records in the time queue is 4, that is, the total number of current records of the request time record is 4, then the requestable number of times for logging in the target website using the user name is 1, that is, the output prompt information may include: "the current login fails, and login can also be attempted 1 time".
In summary, according to the user name locking method provided in this embodiment, on one hand, the same processing manner is adopted for each user name that cannot be logged in, that is, the same time queue is established and the same enqueue and dequeue manners are adopted, so that a network attacker cannot identify whether the current user name is a registered user name, thereby increasing the difficulty in identifying the registered user name and further improving the network security. On the other hand, because the time queue is corresponding to the user name, that is, as long as the time queue is filled up, the user name is locked no matter whether the source of the login request using the user name is the same or not, that is, whether the IP address of the login request using the user name is the same or not, so that even if a network attacker uses a plurality of IPs to perform a library collision attack, the user name can be locked, thereby eliminating the disadvantage that the user name cannot be locked in time when the network attack is performed due to the limitation of the login request times of the same IP.
Third embodiment
In practical application, a user name needs to be registered and a corresponding password needs to be set before a legal user accesses the target website for the first time. Then, the legal user can use the user name and the password to send a login request on a login interface provided by the target website, and after the login is successful, the user can access the target website.
In view of this, the embodiment of the present application further provides a user name locking method, which is mainly specifically introduced for user registration and user access, and the third embodiment will be described with reference to the accompanying drawings.
Referring to fig. 6, the figure is a flowchart of a username locking method provided in this embodiment, and the username locking method provided in this embodiment includes the following steps:
s601: receiving a registration request for the target website, wherein the registration request carries registration information, and the registration information comprises the user name and a registration password corresponding to the user name.
It should be noted that the user can input a user name and a password in the registration interface provided by the target website, and click the "register" button. After the user clicks the "register" button, the user may be considered to have successfully sent a registration request for the target website. That is, after the user clicks the "register" button, the server may be considered to have received the registration request.
S602: and synchronously writing the registration information into a database and a cache.
After receiving the registration request, the server synchronously writes the user name carried in the registration request and the registration password corresponding to the user name into a cache and a database, that is, the database and the cache both store the user name and the registration password corresponding to the user name.
S603: and receiving a current login request for the target website, wherein the current login request carries a user name and a login password.
It should be noted that step S603 is the same as step S101 in the first embodiment, and specific description may refer to the description of the portion S101 in the first embodiment, which is not repeated herein.
S604: and querying a preset storage space, wherein the preset storage space is the database or the cache, and each registered user name of the target website and a registration password corresponding to the registered user name are stored in the preset storage space.
It will be appreciated that, with respect to each registered username and the registration password corresponding to that registered username, the username has been synchronously written to the database and cache at the time the username was registered, and thus, all registered usernames and the registration password corresponding to the registered username are stored in the database and cache. Based on this, it can be determined whether the user name exists in the database or cache by querying the database or cache.
S605: and judging whether the user name is stored in the preset storage space, if so, executing step S606, and if not, executing step S608.
Specifically, when S605 is implemented, the user name carried in the current login request may be matched with the registered user name stored in the preset storage space, and if the user name carried in the current login request can be matched with the registered user name, it is indicated that the user name carried in the current login request is the registered user name, otherwise, the user name carried in the current login request is the unregistered user name.
It can be understood that, in order to ensure reliable operation of the database, some unnecessary read-write operations can be avoided as much as possible, because both the database and the cache store the user name and the registration password corresponding to the user name. Therefore, in a possible implementation manner, the user name carried in the current login request can be matched with the registered user name stored in the cache, so that on one hand, the reading operation on the database is reduced, and the reliability of the operation of the database is improved, and on the other hand, the problem that when a network attacker carries out a database collision attack, and a large number of login requests directly reach the server, the pressure of the database of the server is increased sharply, so that the database is possibly crashed, and the whole login system is out of order is solved.
S606: and inquiring a preset storage space, and acquiring a registration password corresponding to the user name.
As an example, since the preset storage space stores a corresponding relationship between a registered user name and a registration password corresponding to the user name, the registration password corresponding to the user name can be found from the corresponding relationship according to the user name.
S607: and judging whether the inquired registration password is the same as the login password, if not, executing the step S608.
It can be understood that, when the login password carried by the current login request is the same as the queried registration password, the user successfully logs in. And when the login password carried by the current login request is different from the inquired login password, the fact that the user name carried by the current login request is not matched with the login password is shown.
S608: and judging whether the user name meets a preset locking condition or not according to the current login request and the historical login request carrying the user name, if so, executing step 609, and if not, executing step 610.
S609: and locking the user name.
S610: and outputting prompt information, wherein the prompt information is information which represents that login fails and allows re-login.
It should be noted that steps S608 to S610 are the same as steps S104 to S106 in the first embodiment, and specific description may refer to descriptions of the portions S104 to S106 in the first embodiment, which are not repeated herein.
On one hand, according to the user name locking method provided by the embodiment, the same processing mode is adopted for each user name which cannot realize login, so that a network attacker cannot identify whether the current user name is a registered user name, the identification difficulty of the registered user name is improved, and the network security is improved. On the other hand, when the user name carried in the current login request is judged to be the registered user name and the user name carried in the current login request is judged to be matched with the login password, the registered user name and the login password stored in the cache are inquired preferentially, on one hand, the reading operation on the database can be reduced, the running reliability of the database is improved, and on the other hand, the problem that when a network attacker carries out database collision attack and a large number of login requests directly reach the server, the pressure of the database of the server is increased sharply, the database is possibly crashed, and the whole login system is disabled is solved.
Fourth embodiment
Referring to fig. 7, which is a schematic diagram illustrating a composition of a server according to a fourth embodiment of the present application, where the server 700 includes:
a request receiving unit 701, configured to receive a current login request for a target website, where the current login request carries a user name and a login password;
a user name determining unit 702, configured to determine whether the user name is a registered user name;
a password determining unit 703, configured to determine whether the user name matches the login password if the user name is a registered user name;
a locking judgment unit 704, configured to, if the user name is not matched with the login password, or the user name is not a registered user name, judge whether the user name meets a preset locking condition according to a current login request and a historical login request that carry the user name;
a user name locking unit 705, configured to lock the user name if the preset locking condition is met;
the information prompting unit 706 is configured to output a prompting message if the preset locking condition is not met, where the prompting message represents that the login fails and allows for login again.
In an embodiment of the present application, the lock determination unit 704 may include:
the time recording subunit is used for recording first request time, wherein the first request time is the request time corresponding to the current login request carrying the user name;
the total number determining subunit is used for inquiring the request time record corresponding to the user name and determining the total number of records;
a locking judgment subunit, configured to determine that the user name does not satisfy a preset locking condition if the total number of records is equal to 1;
a time difference calculation unit configured to calculate a time difference between the first request time and a second request time if the total number of records is greater than 1, where the second request time is an earliest request time recorded in the request time record;
the time removing subunit is configured to remove the second request time from the request time record if the time difference is greater than or equal to a preset time threshold, and determine that the user name does not satisfy a preset locking condition;
the locking judgment subunit is further configured to judge whether the total number of records is smaller than a preset number threshold if the time difference is smaller than the preset time threshold; if so, determining that the user name does not meet the preset locking condition, and if not, determining that the user name meets the preset locking condition.
In an embodiment of the application, the information prompting unit may be specifically configured to output the number of times that the user can request to log in the target website; the number of requestable times is a difference value between the preset time threshold and a time record value, and the time record value is a current record total number of the requested time records.
In an embodiment of the present application, the server 700 may further include:
the queue maintenance unit is used for maintaining a time queue corresponding to the user name in a cache;
correspondingly, the time recording subunit may be specifically configured to record a first request time in the time queue;
accordingly, the time removal subunit may be specifically configured to remove the second request time from the time queue.
In an embodiment of the present application, the user name is a registered user name, and the server 700 may further include:
a registration request receiving unit, configured to receive a registration request for the target website, where the registration request carries registration information, and the registration information includes the user name and a registration password corresponding to the user name;
and the registration information writing unit is used for synchronously writing the registration information into a database and a cache.
In an embodiment of the present application, the user name determining unit 702 may include:
the user name inquiring subunit is used for inquiring a preset storage space, wherein the preset storage space is the database or the cache, and each registered user name of the target website and a registration password corresponding to the registered user name are stored in the preset storage space;
a user name judging subunit, configured to judge whether the user name is stored in the preset storage space; if yes, determining that the user name is a registered user name, and if not, determining that the user name is not the registered user name;
accordingly, the password determination unit 703 may include:
the password inquiry subunit is configured to inquire the preset storage space, and acquire a registration password corresponding to the user name;
the password judgment subunit is used for judging whether the inquired registration password is the same as the login password or not; if so, determining that the user name is matched with the login password, and if not, determining that the user name is not matched with the login password.
Further, an embodiment of the present application further provides another server, including: a processor, a memory, a system bus;
the processor and the memory are connected through the system bus;
the memory is configured to store one or more programs, the one or more programs including instructions, which when executed by the processor, cause the processor to perform any of the above-described username locking methods.
Further, an embodiment of the present application further provides a computer-readable storage medium, where instructions are stored in the computer-readable storage medium, and when the instructions are run on a terminal device, the terminal device is caused to execute any implementation method of the above-mentioned user name locking method.
Further, an embodiment of the present application further provides a computer program product, which when running on a terminal device, causes the terminal device to execute any implementation method of the above-mentioned username locking method.
As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that all or part of the steps in the above embodiment methods can be implemented by software plus a necessary general hardware platform. Based on such understanding, the technical solution of the present application may be essentially or partially implemented in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network communication device such as a media gateway, etc.) to execute the method according to the embodiments or some parts of the embodiments of the present application.
It should be noted that, in the present specification, the embodiments are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments may be referred to each other. For the server disclosed by the embodiment, the description is relatively simple because the server corresponds to the method disclosed by the embodiment, and the relevant points can be referred to the description of the method part.
It is further noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the application. Thus, the present application is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims (14)
1. A username locking method, the method comprising:
receiving a current login request for a target website, wherein the current login request carries a user name and a login password;
judging whether the user name is a registered user name or not;
if the user name is the registered user name, judging whether the user name is matched with the login password;
if the user name is not matched with the login password or the user name is not a registered user name, judging whether the user name meets a preset locking condition or not according to a current login request and a historical login request carrying the user name;
if the preset locking condition is met, locking the user name;
if the preset locking condition is not met, outputting prompt information, wherein the prompt information represents login failure and allows login again.
2. The method of claim 1, wherein the determining whether the user name meets a preset locking condition according to a current login request and a historical login request carrying the user name comprises:
recording first request time, wherein the first request time is the request time corresponding to the current login request carrying the user name;
inquiring request time records corresponding to the user name, and determining the total number of records;
if the total number of records is equal to 1, determining that the user name does not meet a preset locking condition;
if the total number of records is greater than 1, calculating a time difference between the first request time and a second request time, wherein the second request time is the earliest request time recorded in the request time records;
if the time difference is greater than or equal to a preset time threshold, removing the second request time from the request time record, and determining that the user name does not meet a preset locking condition;
if the time difference is smaller than the preset time threshold, judging whether the total number of records is smaller than a preset time threshold; if so, determining that the user name does not meet the preset locking condition, and if not, determining that the user name meets the preset locking condition.
3. The method of claim 2, wherein outputting the prompt message comprises:
outputting the number of times that the user name can be requested to log in the target website;
the number of requestable times is a difference value between the preset time threshold and a time record value, and the time record value is a current record total number of the requested time records.
4. The method of claim 2, further comprising:
maintaining a time queue corresponding to the user name in a cache;
accordingly, the recording a first request time includes:
recording a first request time in the time queue;
accordingly, said removing the second request time from the request time record comprises:
removing the second request time from the time queue.
5. The method of any of claims 1 to 4, wherein the username is a registered username, the method further comprising:
receiving a registration request for the target website, wherein the registration request carries registration information, and the registration information comprises the user name and a registration password corresponding to the user name;
and synchronously writing the registration information into a database and a cache.
6. The method of claim 5, wherein the determining whether the username is a registered username comprises:
querying a preset storage space, wherein the preset storage space is the database or the cache, and each registered user name of the target website and a registration password corresponding to the registered user name are stored in the preset storage space;
judging whether the user name is stored in the preset storage space or not;
if yes, determining that the user name is a registered user name, and if not, determining that the user name is not the registered user name;
correspondingly, the judging whether the user name is matched with the login password comprises:
inquiring the preset storage space, and acquiring a registration password corresponding to the user name;
judging whether the inquired registration password is the same as the login password or not;
if so, determining that the user name is matched with the login password, and if not, determining that the user name is not matched with the login password.
7. A server, characterized in that the server comprises:
the system comprises a request receiving unit, a login processing unit and a login processing unit, wherein the request receiving unit is used for receiving a current login request for a target website, and the current login request carries a user name and a login password;
a user name judging unit, configured to judge whether the user name is a registered user name;
the password judgment unit is used for judging whether the user name is matched with the login password or not if the user name is the registered user name;
the locking judgment unit is used for judging whether the user name meets a preset locking condition according to a current login request and a historical login request carrying the user name if the user name is not matched with the login password or the user name is not a registered user name;
a user name locking unit, configured to lock the user name if the preset locking condition is met;
and the information prompting unit is used for outputting prompting information if the preset locking condition is not met, wherein the prompting information represents login failure and allows login again.
8. The server according to claim 7, wherein the lock determination unit includes:
the time recording subunit is used for recording first request time, wherein the first request time is the request time corresponding to the current login request carrying the user name;
the total number determining subunit is used for inquiring the request time record corresponding to the user name and determining the total number of records;
a locking judgment subunit, configured to determine that the user name does not satisfy a preset locking condition if the total number of records is equal to 1;
a time difference calculation unit configured to calculate a time difference between the first request time and a second request time if the total number of records is greater than 1, where the second request time is an earliest request time recorded in the request time record;
the time removing subunit is configured to remove the second request time from the request time record if the time difference is greater than or equal to a preset time threshold, and determine that the user name does not satisfy a preset locking condition;
the locking judgment subunit is further configured to judge whether the total number of records is smaller than a preset number threshold if the time difference is smaller than the preset time threshold; if so, determining that the user name does not meet the preset locking condition, and if not, determining that the user name meets the preset locking condition.
9. The server according to claim 8, wherein the information prompting unit is specifically configured to output a number of requestable times for logging in to the target website using the user name; the number of requestable times is a difference value between the preset time threshold and a time record value, and the time record value is a current record total number of the requested time records.
10. The server of claim 8, further comprising:
the queue maintenance unit is used for maintaining a time queue corresponding to the user name in a cache;
correspondingly, the time recording subunit may be specifically configured to record a first request time in the time queue;
accordingly, the time removal subunit may be specifically configured to remove the second request time from the time queue.
11. A server according to any of claims 7 to 10, wherein the username is a registered username, the server further comprising:
a registration request receiving unit, configured to receive a registration request for the target website, where the registration request carries registration information, and the registration information includes the user name and a registration password corresponding to the user name;
and the registration information writing unit is used for synchronously writing the registration information into a database and a cache.
12. The server according to claim 11, wherein the user name judging unit includes:
the user name inquiring subunit is used for inquiring a preset storage space, wherein the preset storage space is the database or the cache, and each registered user name of the target website and a registration password corresponding to the registered user name are stored in the preset storage space;
a user name judging subunit, configured to judge whether the user name is stored in the preset storage space; if yes, determining that the user name is a registered user name, and if not, determining that the user name is not the registered user name;
accordingly, the password judgment unit includes:
the password inquiry subunit is configured to inquire the preset storage space, and acquire a registration password corresponding to the user name;
the password judgment subunit is used for judging whether the inquired registration password is the same as the login password or not; if so, determining that the user name is matched with the login password, and if not, determining that the user name is not matched with the login password.
13. A server, comprising: a processor, a memory, a system bus;
the processor and the memory are connected through the system bus;
the memory is to store one or more programs, the one or more programs comprising instructions, which when executed by the processor, cause the processor to perform the method of any of claims 1-6.
14. A computer-readable storage medium having stored therein instructions that, when executed on a terminal device, cause the terminal device to perform the method of any one of claims 1-6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711284991.0A CN107959683B (en) | 2017-12-07 | 2017-12-07 | User name locking method and server |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711284991.0A CN107959683B (en) | 2017-12-07 | 2017-12-07 | User name locking method and server |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107959683A CN107959683A (en) | 2018-04-24 |
| CN107959683B true CN107959683B (en) | 2020-09-25 |
Family
ID=61958235
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201711284991.0A Active CN107959683B (en) | 2017-12-07 | 2017-12-07 | User name locking method and server |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107959683B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110941661A (en) * | 2019-12-30 | 2020-03-31 | 东软集团股份有限公司 | Data management method, device and equipment |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104125225A (en) * | 2014-07-28 | 2014-10-29 | 浪潮(北京)电子信息产业有限公司 | Method and device for user login authentication in cloud data centre |
| CN105635107A (en) * | 2014-11-26 | 2016-06-01 | 京瓷办公信息系统株式会社 | Authentication apparatus and authentication method |
| CN106251214A (en) * | 2016-08-02 | 2016-12-21 | 东软集团股份有限公司 | account monitoring method and device |
| CN107135201A (en) * | 2017-04-01 | 2017-09-05 | 网易（杭州）网络有限公司 | A kind of webserver login authentication method and device |
| CN107438049A (en) * | 2016-05-25 | 2017-12-05 | 百度在线网络技术（北京）有限公司 | A kind of malice logs in recognition methods and device |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9171143B2 (en) * | 2013-12-19 | 2015-10-27 | Verizon Patent And Licensing Inc. | System for and method of generating visual passwords |
| US20160125522A1 (en) * | 2014-11-03 | 2016-05-05 | Wells Fargo Bank, N.A. | Automatic account lockout |
-
2017
- 2017-12-07 CN CN201711284991.0A patent/CN107959683B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104125225A (en) * | 2014-07-28 | 2014-10-29 | 浪潮(北京)电子信息产业有限公司 | Method and device for user login authentication in cloud data centre |
| CN105635107A (en) * | 2014-11-26 | 2016-06-01 | 京瓷办公信息系统株式会社 | Authentication apparatus and authentication method |
| CN107438049A (en) * | 2016-05-25 | 2017-12-05 | 百度在线网络技术（北京）有限公司 | A kind of malice logs in recognition methods and device |
| CN106251214A (en) * | 2016-08-02 | 2016-12-21 | 东软集团股份有限公司 | account monitoring method and device |
| CN107135201A (en) * | 2017-04-01 | 2017-09-05 | 网易（杭州）网络有限公司 | A kind of webserver login authentication method and device |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107959683A (en) | 2018-04-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108737418B (en) | Identity authentication method and system based on block chain | |
| WO2020248658A1 (en) | Abnormal account detection method and apparatus | |
| WO2018228036A1 (en) | Verification method and device, server, and readable storage medium | |
| US20090031405A1 (en) | Authentication system and authentication method | |
| TW201734874A (en) | Identity registration method and device | |
| CN110232265B (en) | Dual identity authentication method, device and system | |
| US20220376889A1 (en) | Lifecycle administration of domain name blockchain addresses | |
| CN104144419A (en) | Identity authentication method, device and system | |
| US10630574B2 (en) | Link processing method, apparatus, and system | |
| WO2016004241A1 (en) | Login using two-dimensional code | |
| CN104580075A (en) | User login validation method, device and system | |
| CN106656455B (en) | Website access method and device | |
| CN112118269A (en) | Identity authentication method, system, computing equipment and readable storage medium | |
| CN110222085B (en) | Processing method and device for certificate storage data and storage medium | |
| CN107911381A (en) | Access method, system, server-side and the client of application programming interface | |
| US20180115542A1 (en) | Security mechanism for multi-tiered server-implemented applications | |
| US8656468B2 (en) | Method and system for validating authenticity of identity claims | |
| EP2666099A1 (en) | System and method for transmitting and filtering instant messaging information | |
| CN114928452B (en) | Access request verification method, device, storage medium and server | |
| US11087374B2 (en) | Domain name transfer risk mitigation | |
| CN107959683B (en) | User name locking method and server | |
| KR101846778B1 (en) | Method for ID Resolution Service and M2M System applying the same | |
| US8386775B2 (en) | Tolerant key verification method | |
| CN104052720A (en) | Information authentication method and system thereof | |
| CN110728504A (en) | Data processing method, device and equipment of block chain and readable storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |