Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Just wanted to know if this would be considered a good way to handle login process. It doesn't matter which language it is written in.

I will use this fellowing format. - Event (Where it happened)

  1. Connect to the server with user credentials. (Client)
  2. Verify if IP Address is blocked (by looking in a table on the database), if YES then send ERROR saying IP is blocked. (Server)
  3. Verify if account is active, if NO then send an ERROR to client saying account aren't active. (Server)
  4. Verify if account is blocked/banned from server, if YES then send ERROR saying account is blocked or banned from server. (Server)
  5. Compare password hash with database user account password hash, if the compare is NEGATIVE increase the number of attempts in the database associated to IP Address. If 3 are reached then ban the IP Address. (Server)
  6. Login are succesful at this point !

Additionnal Question :

  1. If you look at the point 5. I tried to find a good way to block the actual user which try to login (which doesn't mean its the user owner of the account) but without affecting the real user. What i mean is that if someone else than the owner of the account try to login more than 3 time on the specific account it will get his IP Address banned instead of the account in question. Would it be best to block the account aswell ? for a limited time or something ?


share|improve this question
up vote 5 down vote accepted

In your process, people will get a distinct error code depending on whether the account exists or not. This is often considered somewhat inopportune. It is preferable if it is not possible, for outsider, to know whether a given account name exists; therefore, observable behaviour of your server should be the same in all situations which depend on the account name and lead to a failure: account does not exist, account is disabled, password is wrong. Note that "observable behaviour" includes not only the error code you return, but also the time taken by your server to respond (if you use slow-and-salted password hashing à la bcrypt -- and you really shoud do that -- then password verification can take a non-negligible time which can be measured from the outside).

Banning an IP address after a few failures has the following caveats:

  • The IP address you see could be shared between several people, in case of NAT. This is very common in organizations. Also common are HTTP proxies. You don't want three failures from one user to induce your server into banning a complete university, or even all the customers of a specific ISP.

  • Sometimes, people forget their password. This happens a lot. So you will get "legitimate" login failures. Such users will want to use the "I forgot my password" process, and they will want to do it immediately. Therefore, the ban must not be long (say, ban for one minute at most).

  • Attackers who are intent on trying a lot of potential login+password pairs will have relatively little trouble finding relay hosts to work around your IP-based banning. E.g. Tor, by construction, decreases the efficiency of IP banning.

Therefore I do not recommend IP address banning on a general basis: it has a high risk of disrupting service for normal users, while not being very effective against average attackers. IP banning is useful against burst situations with crude attackers (e.g. automatic attacks from botnets trying to replicate), with tools like Fail2ban, but they can backfire, so caution must be exercised.

Note that blocking accounts can also backfire:

  • Blocking an account after too many failures means that anybody can block the accounts of other people.

  • Attackers who try many login+password pairs can spread their attempts over a lot of distinct logins, avoiding the blocking feature.

Reasonable solutions involve time-limited blocks (lock an account for one minute or so after a few wrong passwords) coupled with time-limited IP banning when a very suspicious access pattern is identified (a lot of connection attempts from the same IP). They will not give strong protection (only strong user passwords will), but they may help in reducing the noise from low-grade attackers and let you concentrate on the few cases where attackers exhibit an unusual amount of competence.

share|improve this answer
Very interesting answer. There few things in there which i already though about. Like the fact that i should really send the same error to the user in any failure case. Should i show something like 'An error happened while trying to log in.' for any case you mentionned ? Also from what i am reading in your solution i should make the ip/account block transparent to the user with the same error ? – Rushino Feb 22 '13 at 16:17
Common login interfaces show a message "invalid username or password" which covers both grounds, and human users are already trained to see such messages. – Thomas Pornin Feb 22 '13 at 16:18
So your saying the same message 'invalid username or password' should be sent to the user even if the ip or account is blocked ? won't he wonder what going on at some point ? (This is a bit overkill situation) I mean maybe after 3 or 4 tries he finally remember the correct password but his account will be blocked and he won't know why. – Rushino Feb 22 '13 at 16:20
You should send it also if the account is blocked, otherwise an attacker can identify a "true account" by his ability of blocking it. For a blocked IP, your server does not respond at all, so there should be no message; alternatively, you can have a specific "go away" answer if (and only if) IP blocking is not dependent on target account name (that is, you block the IP after ten failures, regardless of what failed). – Thomas Pornin Feb 22 '13 at 16:27
One thing to note though is that you would have to ban an ip after 3 attempted logins on accounts that dont exist as well. Otherwise n attacker could figure out what accounts exist by trying to lock one out. – Eric Feb 22 '13 at 17:06

Just a quick addition to the answer above. You could create a new mysql table where you save the username, times tried to login (errors), and the timestamp the blocking started (standard: NULL). A username doesn't have to exists to block it. That way, it becomes possible to display error messages and block messages, because you never know for sure if the account exists or not.

share|improve this answer
Please don't refer to "the answer above" (or "below") on Stack Exchange. The relative order of the answers can easily change over time as well as being dependent on user preferences, so such references become meaningless. Instead, mention the name of the person who posted the answer, possibly along with a "share" link. This is much less likely to change over time. – Michael Kjörling Sep 22 '13 at 15:02

I tried to find a good way to block the actual user which try to login (which doesn't mean its the user owner of the account) but without affecting the real user. What i mean is that if someone else than the owner of the account try to login more than 3 time on the specific account it will get his IP Address banned instead of the account in question

If you were able to tell a hacker from the legitimate user at this point, why bother with a login form in the first place? Just let the legitimate user pass.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.