Algorithm against Brute-force
I have been thinking of an algorithm against attacks of the type Brute-force that, as we saw in the case of iCloud , can generate great headaches if treated with indifference.
Initially I thought of this stream:
Login attempt:
[define uma session "tentativas" para o usuário (caso ainda não exista)]↓
[incrementa o valor da session em 1]↓
[faz a verificação no banco]↓
[login correto: efetua login]-[login errado: volta à pagina de login]↓
[verifica o número de tentativas da session]↓
[ >= 5: bloqueia tela de login por 1 min]-[ < 5: Deixa tentar denovo]
A session-only check would be enough? Or would it be worth adding cookies, or some other method of checking?
6 answers
Utluiz's Response gives a good overview, as well as drawing attention to an important point: if your "safety" is less, 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 to give an opinion, as I am also not a security expert. But if your goal is simply to prevent a single [arbitrary user, of course] from being hacked (i.e. someone tries to log in multiple times with the same username and different passwords), a viable solution is to progressively increase the "cost" of logging in with that user:
- with each unsuccessful login attempt, slightly increase the time interval required to try again with that user (no matter where that login came from).
- if the number passes a certain limit (say, 3) ask for a captcha along with the login.
- if it increases further, send an email alerting the user of the fact (but not necessarily blocking it).
- if the number is excessive (and then I will not risk saying what would be excessive) then yes block that user account.
You can do the same per IP address, to make the simplest attacks a little difficult, but as already said This is best done outside the application layer. And in any case, such a measure is more likely to negatively affect a legitimate user (eg.: I forgot my password, but I remember that it is one of the A, B, C and D) than an attacker (who already expects this type of security measure and takes proactive actions to avoid them).
P.S. supplementing, keep in mind that a well-made password hash also helps protect against brute-force attacks, and that a two-factor authentication is an even better way to insure against password theft (which are generally weak, making it a huge challenge to protect them not from malicious attacks). import the chosen method).
Warning: I am not an expert in security or this type of attack.
Cookies and Session do not resolve
Cookies and Session not are suitable places to place this type of security.
Cookies are the responsibility of the customer (usually the browser), therefore easily manipulated.
The user session, despite being on the server, is just a data structure associated with an identifier, which is usually in a Cookie or URL through URL Rewriting .
In the above two cases, requests in order to perform a brute force attack simply need to simulate a new user with 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 about the application
Attacks involving massive network usage such as this or DoS (denial of Service) usually they are best handled by Firewalls or proxies that filter out excess requests.
Leaving this in charge of the application will bring a 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 cost of a system with less quality.
And an 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 turns out to be very difficult to differentiate a "normal" request from an automated one.
How to detect attacks?
Speaking of differentiating , that's the whole point. How to detect the pattern of artificial requests generated by attacks of genuine requests originated by users?
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 the subject of debate by security experts.
I can even think of small techniques to make it difficult for a hacker to act, but ultimately, it will always be possible for him to identify these techniques and adjust the attack.
Maybe use a captcha or equivalent "human test" it is one of the most effective ways today, but it often hinders usability and there are also guarantees that an automated algorithm that solves these challenges cannot be implemented.
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, suitable tools and consultation with specialists.
Checking 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 (maximum 12 hours) for the exchange of the "forgotten"password.
I DO NOT RECOMMEND THE USE OF COOKIES FOR SECURITY VALIDATIONS!
It is very easy to change the cookie data given to some tools I have already been able to try.
Recommended reading, by less to start: http://en.wikipedia.org/wiki/Session_hijacking
I have read all the answers and agree with all of them in general. However I would like to introduce the topic of server responsiveness or server set.
But before and looking at the question I want to add that, in my opinion, a system should be able and without harming the real users to the detriment of the alleged "hackers" implement an authentication policy that does not block. However, what if you do... that put an arsenal of tools for the very resolve the situation it certainly did not create. Dissatisfied user is a user who does not want to use the service.
Therefore and 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 database the total of attempts before incrementing.
Both the recording of this increment and the validation of the same has to be well oriented, because it is a database as indicated and an attack "brutal force" the calls will succeed and certainly blocking nothing will solve because the service can be clogged with so many accesses that despite the effort of implementation of the counter this will never be effective.
Therefore, security at the level of credential authentication will not be restricted to this issue alone. In @utluiz's answer the phrase:
Security is not just the application
Makes perfect sense and if possible see the whole picture.
To finish say as an example that I have been involved in a project of an "Identity Manager" and I can say that the service contains more than one HTTP server after they access their own cluster to validate credentials with the data pool.
Until I get here many are the security processes used, however and for me one of the best is this separation, where it puts me the possibility to define in the database servers the IP'S of the HTTP servers that can access, without allowing any other access.
And still good monitoring is required.
Warning: I am not an expert in security or this type of Attack
Mode 1
One way that I use and that you can also use is to block LOGIN / email after erring 5 times the password.
The 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 accounts - thank you @ Daniel Omine
Mode 2
Use Captcha
It is clear that none of the techniques already mentioned solve the problem completely. With what we have available, we can do as many have already spoken here:
- missed the password more than 3 times, uses session and requests a captcha.
- missed the password more than 2 times, hitting the captcha, blocks the ip for 2 minutes.
- If the second IP block happens, block the account and request unblocking!
Have people confusing it with DDoS attack that has like objective to reach the source, stopping your application and all the others that share the same server, that is, no one will access anything, including you!