Friendly WEB resource protection against brute force attacks
One of the problems that arise before WEB-resources with personal accounts - brute-force attack. Yes, simple enumeration of all password options for a specific account. Stupid? It is possible, but such an attack can heavily load a resource. In addition, if there is no control over the complexity of the user's password during registration, it may also be successful.
Most often, the issue is solved relatively simply. If the user has entered the wrong password several times, his account is blocked for a while. An alternative solution is to display captcha. Immediately, or after several unsuccessful attempts. Well, let's not forget about 2F authorization, which is almost invulnerable. It would seem - a profit! But not everything is so rosy ...
Let's consider some problems of the described solutions:
Temporary blocking - the user account is temporarily blocked and he cannot get into the system. A real user is experiencing heartache and anguish during the attack. He can not get into the system. And most likely loads your support. And the most interesting thing is that perhaps this is the attacker's goal.
Captcha is a relatively good and effective solution. The truth brings inconvenience to the user, demanding to enter something there additionally. Enough “unpleasant” to embed in the design. Oh yeah ... even this thing, depending on the implementation, may be subject to a DoS attack.
2F authorization- Everything is great. True ... most often this thing is optional. Enable it to counter the attack will not work. It is either there or not. And on some resources, enter 2F authorization, let's say, shoot sparrows from a tank.
I try to create convenient and reliable services. Therefore, I decided to strain my brain a little. And so what happened.
If you use mail, for example mail.ru, and you have 2F authorization installed, you may have already noticed that 2F authorization is only requested for a new “device” when you first log in. Further, the device is considered trusted. And you just need to enter your username and password.
Convenient thing. Usergrandly, so to speak. It is implemented by two tokens. The first identifier of the “device” (defined as devid), and the second session (defined as session). Devid, unlike session, does not lose its relevance even after the user has finished the session. It is transmitted on the next login attempt, and if the login / password is correct and the devid is trusted, 2F is no longer requested. But, if the next login attempt failed, the devid token will immediately faint. And now you need to go through the full path authorization.
This paradigm was taken as a basis. Those. enter the devid token, which will be issued constantly, with any response of the WEB-resource, of course, if it was not in the request.
For the case of 2F authorization, the algorithm described above was, in fact, implemented. And immediately everyone became satisfied. T.ch. it makes no sense to consider it in detail. But the "bells and whistles", it is better to look at the diagram, with explanations:
Even if 2F authentication is not installed, but the input was successful, then the devid token is marked as trusted. It would seem that it makes no sense to do this without authorization 2F. But everything is a little trickier. If we know that devid is trusted, i.e. there was a successful login from it, we at least assume that it was from this device that the real user entered. This is very important information that the described algorithm uses in its work in the reflection attack mode.
A strategy has been adopted: any authorization can occur only in the presence of a valid devid token. A valid devid differs from a trusted one in that it is NOT trusted yet; there were no successful logins, but the system is ready to process authorization requests with it. For one valid token, the number of attempts is limited N times. If an authorization error occurs more than N times in a row, the token is marked as “compromised”. It is transferred to a separate log with statistics of selection. Requests with his participation continue to be processed, but ... it is no longer possible to log in with him. All that happens is the accumulation of activity statistics.
So the stupidest attacks are fought. For example, if an attacker, ignoring devid, tries to log in to the system or if he was unable to understand the logic of devid operation (how do he know how many login attempts are made with the same devid?), His requests are terminated.
Own front knows that after N times unsuccessful attempts to enter with one devid, it is already “rotten”. Now you need to get a new token, before another login attempt.
It would seem that nonsense? Front work out attempts to enter ... but, as I said above, all smarter. If the user works through the regular front, the probability that he is really trying to attack the system is negligible. Paired with the password complexity control system when registering a user, this is completely futile. Most likely, a real user, really trying to remember your password.
So what's the trick? In the fact that on the back we generate the same valid devid with a certain time limit. For example, no more than 1000 pieces per minute. If suddenly this limit is exceeded, the attack mode is cut. And then either you can go radically and stop the devid emission for a while, which will dramatically cool the attacker's ardor, or reduce the amount of valid devid generation. And you can include the same captcha for all valid, but untrusted devid.
Thus, a flexible system of control and management of attacks. Reliable metrics are formed on which monitoring can trigger triggering an alarm. Accumulated statistics can be converted to blocking rules, etc.
A friendly system is because those users who previously entered into it, i.e. have a trusted devid not even notice the attack. They will be skipped by the system without problems.
Now profit. This algorithm has proven itself quite well on resources with a very high load. There were, among other things, DoS attempts on the algorithm itself, but even here it showed itself with dignity.
Most often, the issue is solved relatively simply. If the user has entered the wrong password several times, his account is blocked for a while. An alternative solution is to display captcha. Immediately, or after several unsuccessful attempts. Well, let's not forget about 2F authorization, which is almost invulnerable. It would seem - a profit! But not everything is so rosy ...
Let's consider some problems of the described solutions:
Temporary blocking - the user account is temporarily blocked and he cannot get into the system. A real user is experiencing heartache and anguish during the attack. He can not get into the system. And most likely loads your support. And the most interesting thing is that perhaps this is the attacker's goal.
Captcha is a relatively good and effective solution. The truth brings inconvenience to the user, demanding to enter something there additionally. Enough “unpleasant” to embed in the design. Oh yeah ... even this thing, depending on the implementation, may be subject to a DoS attack.
2F authorization- Everything is great. True ... most often this thing is optional. Enable it to counter the attack will not work. It is either there or not. And on some resources, enter 2F authorization, let's say, shoot sparrows from a tank.
I try to create convenient and reliable services. Therefore, I decided to strain my brain a little. And so what happened.
If you use mail, for example mail.ru, and you have 2F authorization installed, you may have already noticed that 2F authorization is only requested for a new “device” when you first log in. Further, the device is considered trusted. And you just need to enter your username and password.
Convenient thing. Usergrandly, so to speak. It is implemented by two tokens. The first identifier of the “device” (defined as devid), and the second session (defined as session). Devid, unlike session, does not lose its relevance even after the user has finished the session. It is transmitted on the next login attempt, and if the login / password is correct and the devid is trusted, 2F is no longer requested. But, if the next login attempt failed, the devid token will immediately faint. And now you need to go through the full path authorization.
This paradigm was taken as a basis. Those. enter the devid token, which will be issued constantly, with any response of the WEB-resource, of course, if it was not in the request.
For the case of 2F authorization, the algorithm described above was, in fact, implemented. And immediately everyone became satisfied. T.ch. it makes no sense to consider it in detail. But the "bells and whistles", it is better to look at the diagram, with explanations:
Even if 2F authentication is not installed, but the input was successful, then the devid token is marked as trusted. It would seem that it makes no sense to do this without authorization 2F. But everything is a little trickier. If we know that devid is trusted, i.e. there was a successful login from it, we at least assume that it was from this device that the real user entered. This is very important information that the described algorithm uses in its work in the reflection attack mode.
A strategy has been adopted: any authorization can occur only in the presence of a valid devid token. A valid devid differs from a trusted one in that it is NOT trusted yet; there were no successful logins, but the system is ready to process authorization requests with it. For one valid token, the number of attempts is limited N times. If an authorization error occurs more than N times in a row, the token is marked as “compromised”. It is transferred to a separate log with statistics of selection. Requests with his participation continue to be processed, but ... it is no longer possible to log in with him. All that happens is the accumulation of activity statistics.
So the stupidest attacks are fought. For example, if an attacker, ignoring devid, tries to log in to the system or if he was unable to understand the logic of devid operation (how do he know how many login attempts are made with the same devid?), His requests are terminated.
Own front knows that after N times unsuccessful attempts to enter with one devid, it is already “rotten”. Now you need to get a new token, before another login attempt.
It would seem that nonsense? Front work out attempts to enter ... but, as I said above, all smarter. If the user works through the regular front, the probability that he is really trying to attack the system is negligible. Paired with the password complexity control system when registering a user, this is completely futile. Most likely, a real user, really trying to remember your password.
So what's the trick? In the fact that on the back we generate the same valid devid with a certain time limit. For example, no more than 1000 pieces per minute. If suddenly this limit is exceeded, the attack mode is cut. And then either you can go radically and stop the devid emission for a while, which will dramatically cool the attacker's ardor, or reduce the amount of valid devid generation. And you can include the same captcha for all valid, but untrusted devid.
Thus, a flexible system of control and management of attacks. Reliable metrics are formed on which monitoring can trigger triggering an alarm. Accumulated statistics can be converted to blocking rules, etc.
A friendly system is because those users who previously entered into it, i.e. have a trusted devid not even notice the attack. They will be skipped by the system without problems.
Now profit. This algorithm has proven itself quite well on resources with a very high load. There were, among other things, DoS attempts on the algorithm itself, but even here it showed itself with dignity.