The answer from the utluiz gives a good overview, and draws attention to an important point: if your "safety" is minus, you are the target of a brute force attack; if it is too much, you are the target of a DoS attack.

How to solve this, I will not risk opinion, because I am also not a security expert. But if your goal is simply to prevent a single user from being hacked (ie someone tries to login multiple times with the same username and different passwords), a workable solution is to increase progressively the "cost" of logging in with this user:

• For each unsuccessful login attempt, slightly increase the amount of time it takes to try again with that user (no matter where that login comes from) .
• If the number goes beyond a certain limit (say, 3) ask for a captcha along with the login.
• If it increases further, send an email warning the user of the fact (but not necessarily blocking it).
• If the number is excessive (and I will not risk saying what would be excessive) then block that user account.

You can do the same by IP address, to make the simplest attacks somewhat difficult, but as already mentioned, this is best done outside the application layer. And anyway, such a measure is more likely to negatively affect a legitimate user (eg, I forgot my password, but I remember it is one of A, B, C, and D) than an attacker of security measure and takes proactive actions to avoid them).

P.S. In addition, remember that a well-crafted password hash also helps protect against brute-force attacks, and that a two-factor authentication is an even better way to protect against password stealing (which is often weak , making it a huge challenge to protect them no matter what method you choose).

  

Warning: I am not a security expert or this type of attack.

Cookies and Session do not resolve

Cookies and Session are not suitable places to place this type of security.

Cookies are the responsibility of the client (usually the browser), therefore easily manipulated.

The User Session, although it stays on the server, is just a data structure associated with an identifier, which is usually in a Cookie or in the URL through URL Rewriting .

In the two cases above, requests to perform a brute-force attack simply need to simulate a new user for each request, as if it were someone who had just opened the browser, causing the server to automatically generate a new session.

Security is not just the application

/ p>

Leaving this in charge of the application will bring complexity to it and will make the team spend time implementing something that is not part of the scope of the system. This distraction almost always comes at the expense of a system with less quality.

And the IP?

A simple but naive technique would be to limit the number of requests using the IP address.

This works in a simple attack, coming from only one source. However, more sophisticated distributed attacks will control multiple sources and it is very difficult to differentiate a "normal" request from an automated one.

How to detect attacks?

Speaking of differentiate , that's the whole point. How can I detect the pattern of artificial requests generated by user-generated attacks?

The answer to this question makes it possible to effectively prevent brute-force attacks.

I will not try to answer this here, as it will be discussed by security experts.

I can even think of little techniques to hinder a hacker's action, but ultimately, it will always be possible for him to identify those techniques and adjust the attack.

Perhaps using a captcha or equivalent "human test" is one of the most effective ways today, however it often disrupts usability and there are also guarantees that an automated algorithm can not be implemented that solves these challenges.

Considerations

The purpose of this answer is to inform web application developers not to try to reinvent security using "naive" techniques. At the same time, I want to say that security should be a concern, but it requires further study, appropriate tools and expert consultation.

Verifying using session only is, in my opinion, insufficient!

I recommend blocking the account after a certain number of attempts, and proceed with sending an email with a temporary password (a maximum of 12 hours) to change the "forgotten" password.

I DO NOT RECOMMEND COOKIE'S USE OF SECURITY VALIDATIONS!

It's very easy to change the cookie data given to some tools I've already tried.

Recommended reading, at least to start: link

  

Warning: I am not a security expert or this type of attack

Mode 1

One mode I use and you can use is also to block LOGIN / EMAIL after 5 times the password.

LOGIN / EMAIL is only unlocked after changing the password (send a link to the registered email to enter a new password)

One problem with this technique is that it makes it possible to block other people's accounts - thanks @Daniel Omine

Mode 2

Using Captcha

I have read all the answers and agree with all of them in general. However, I would like to introduce the server or server farm responsiveness theme.

But before looking at the question I want to add that, in my opinion, a system should be able and without harming the actual users to the detriment of the supposed "hackers" implement an authentication policy that does not block. However, and if you do ... you put an arsenal of tools to solve your own situation that you certainly did not create. Unsatisfied user is a user who does not want to use the service.

So in my opinion the user first.

After and following my first paragraph ... Say that before the algorithm presented the number of attempts will have to be saved, but possibly only after checking the total number of attempts before incrementing in the database.

Both the recording of this increment as well as the validation of it must be well oriented, because if it is a database as indicated and a "brutal force" attack the calls will succeed and certainly block you from nothing it will solve because the service can be clogged with so many accesses that despite the effort of implementing the counter this will never be effective.

Therefore, credential authentication security will not restrict itself to this issue alone. In the @utluiz response the phrase:

  

Security is not just about the application

It makes perfect sense and if possible to see the whole picture.

To end by saying as an example that I have been involved in an "identity manager" project and I can say that the service contains more than one HTTP server then they access their own cluster to validate credentials next to the data pool.

Until I get here many security processes are used, however, and for me one of the best is this separation, where it allows me to define the IP's of the HTTP servers that can access, without allow any other access.

And yet good monitoring is required.

Of course none of the techniques mentioned above solves the problem completely. With what we have available, we can do as many have already said here:

• You have missed the password more than 3 times, use session and request a captcha.
• Failed password more than 2 times, hit captcha, block ip for 2 minutes.
• If the second IP lock occurs, lock the account and request unblocking!

There are people confusing with DDoS attack that aims to reach the source, stopping your application and all others that share the same server, that is, nobody will access anything, including you!