Add flooding prevention

[arthurnn]

Someone could flood the login system writing a robot that would input emails every second, preventing the real user to login.
We could prevent more than 10 logins per IP, or even show a captcha after 3 tries.

[henriquearcoverde]

Using a CAPTCHA to avoid the automation of a attack in web applications is a good solution. However, using the IP as a "flag" to determine if the CAPTCHA must be performed or not is not the best practice. In this case in specific, I believe that is better to use the login (at the server, obviously).

#1 - When you use the IP in a web application (more specifically, only the IP) I suppose that you're probably taking a public IP address. Users in a private network users usually share a public IP address. If you prompt a CAPTCHA using only the IP to decide this, you can't guarantee that that request came from a the same user (in this case HTTP user). The collateral effect of this approach is: you may prompt a CAPTCHA for users that should not receive a CAPTCHA prompt.

#2 - The internet service providers usually don't give to the users a static IP real address. I this case, the attacker may change his IP address anytime he needs.

#3 - By using a IP address approach you still got a problem with distributed attacks. (since they have different IP address)