How to strengthen password protection "12345" from brute-force attack
Object: web login form.
Given the task: to strengthen the protection of a user account from the selection of a simple password to his account, using a minimum of funds.
What is the minimum of funds? It does not use reference tables for blocking by IP address and User-Agent. Do not use unnecessary requests to the system, do not litter the authorization system with unnecessary cycles.
And, to fulfill a completely magical requirement - even if the bot enters the necessary login and password ... do not let it enter, but let the real user in.
')
Is it possible to do so? In theory, of course not. But in practice, in private and under certain conditions, as it turned out, it is quite possible.
I invite under the cat for details.
So, suppose that our user’s login is “test” and the password is “12345”. Nasty bot has connected its dictionary of generated passwords, and is ready to work at a speed of 700 passwords per second. He knows that the username is “test”. The situation is sad: the password "12345" will be calculated in a very short time. The user, meanwhile, opened the site and began to enter the login and password into the web login form.
Let's make changes to the authorization system, while none of them started their work, and trouble did not happen.
The magic will be in the third variable, which should be “pasted” to the login-password pair. I called it touch .
Every time when someone receives (attention: receives , but does not request!) Login password, the date of “touch” for the user “test” is updated for the current date-time:
Suppose the bot started the first iteration and suggested the password “1” for the login “test” in 2014-12-13 15:00:00. It is running a login_check controller, which reads a login-password pair from the database, which no one “touched” for 2 seconds! Where do these 2 seconds come from ?! This will be further.
This pair of login-password is located. The difference between the last “touch” and the current time is 1 hour. Therefore, the record returns successfully to our request.
First, the login-password pair is matched and login_check concludes that “test / 12345” is not equal to “test / 1”. The controller returns "auth error". And then the date of “touch” for the user “test” is updated to the current one: '2014-12-13 15:00:00'.
The bot proceeds to the next iteration: it tries the password "2".
The speed of the bot is measured in microseconds. He is trying to log in immediately: in '2014-12-13 15:00:00'.
And here our algorithm comes into action - the condition on the “touch” parameter is no longer fulfilled. 2 seconds have not passed yet. Fail.
The login_check controller modified by our logic cannot receive a login-password pair.
The record exists, but its “touch” date is still too “fresh.”
And she is no longer in the sample. And if there is no such login-password pair, the controller will respond to the bot “auth error”.
The bot does not give up, continues selection and, finally, comes to the correct password "12345".
The probability that it is the current attempt will return success - extremely and extremely small. 1/700 for every login attempt! That is, if earlier it was 1: 1, now it is 1: 700. And the faster the bot, the greater the likelihood that it will fail.
As a result, only a very small part of the passwords will be really verified. The rest will receive false positives, even if they are correct.
And what about the user?
Let's start with the user. The user, unlike a bot, enters the data in a web form with his hands through the keyboard and looks at the monitor with visual organs. And the flexibility of its algorithmic abilities is much better than a bot. In fact, the user is in some way an artificial intelligence. So, part of the logic already lies in it. And we will use it!
When a user sees an authorization error, he often rewrites the password again. Even if the password he just hammered himself. Even if the password is substituted automatically from the password-manager. I did this before I applied my simple password protection system.
Yes, I promised to tell you about two seconds. I tell:
Two seconds is the optimal time for which the user performs data correction operations and makes the next attempt to enter. In these two seconds, the user fits completely. If the user does not meet, he can always try again and during this time the touch action is probably canceled.
Finally.
What will happen if the bot learns about the 2-second delay? If we apply our test data, this means that the effectiveness of the bot will decrease: only 1 attempt to select a password instead of 1400.
PS I really want to hear criticism, because the system has already been implemented in one project, and has not yet created a single ticket with the problem of access to the system.
Thank you in advance.
Given the task: to strengthen the protection of a user account from the selection of a simple password to his account, using a minimum of funds.
What is the minimum of funds? It does not use reference tables for blocking by IP address and User-Agent. Do not use unnecessary requests to the system, do not litter the authorization system with unnecessary cycles.
And, to fulfill a completely magical requirement - even if the bot enters the necessary login and password ... do not let it enter, but let the real user in.
')
Is it possible to do so? In theory, of course not. But in practice, in private and under certain conditions, as it turned out, it is quite possible.
I invite under the cat for details.
So, suppose that our user’s login is “test” and the password is “12345”. Nasty bot has connected its dictionary of generated passwords, and is ready to work at a speed of 700 passwords per second. He knows that the username is “test”. The situation is sad: the password "12345" will be calculated in a very short time. The user, meanwhile, opened the site and began to enter the login and password into the web login form.
Let's make changes to the authorization system, while none of them started their work, and trouble did not happen.
The magic will be in the third variable, which should be “pasted” to the login-password pair. I called it touch .
Every time when someone receives (attention: receives , but does not request!) Login password, the date of “touch” for the user “test” is updated for the current date-time:
login/password/touch: 'test', '12345', '2014-12-13 14:00:00'. Suppose the bot started the first iteration and suggested the password “1” for the login “test” in 2014-12-13 15:00:00. It is running a login_check controller, which reads a login-password pair from the database, which no one “touched” for 2 seconds! Where do these 2 seconds come from ?! This will be further.
This pair of login-password is located. The difference between the last “touch” and the current time is 1 hour. Therefore, the record returns successfully to our request.
First, the login-password pair is matched and login_check concludes that “test / 12345” is not equal to “test / 1”. The controller returns "auth error". And then the date of “touch” for the user “test” is updated to the current one: '2014-12-13 15:00:00'.
The bot proceeds to the next iteration: it tries the password "2".
The speed of the bot is measured in microseconds. He is trying to log in immediately: in '2014-12-13 15:00:00'.
And here our algorithm comes into action - the condition on the “touch” parameter is no longer fulfilled. 2 seconds have not passed yet. Fail.
The login_check controller modified by our logic cannot receive a login-password pair.
The record exists, but its “touch” date is still too “fresh.”
And she is no longer in the sample. And if there is no such login-password pair, the controller will respond to the bot “auth error”.
The bot does not give up, continues selection and, finally, comes to the correct password "12345".
The probability that it is the current attempt will return success - extremely and extremely small. 1/700 for every login attempt! That is, if earlier it was 1: 1, now it is 1: 700. And the faster the bot, the greater the likelihood that it will fail.
As a result, only a very small part of the passwords will be really verified. The rest will receive false positives, even if they are correct.
And what about the user?
Let's start with the user. The user, unlike a bot, enters the data in a web form with his hands through the keyboard and looks at the monitor with visual organs. And the flexibility of its algorithmic abilities is much better than a bot. In fact, the user is in some way an artificial intelligence. So, part of the logic already lies in it. And we will use it!
When a user sees an authorization error, he often rewrites the password again. Even if the password he just hammered himself. Even if the password is substituted automatically from the password-manager. I did this before I applied my simple password protection system.
Yes, I promised to tell you about two seconds. I tell:
Two seconds is the optimal time for which the user performs data correction operations and makes the next attempt to enter. In these two seconds, the user fits completely. If the user does not meet, he can always try again and during this time the touch action is probably canceled.
Finally.
What will happen if the bot learns about the 2-second delay? If we apply our test data, this means that the effectiveness of the bot will decrease: only 1 attempt to select a password instead of 1400.
PS I really want to hear criticism, because the system has already been implemented in one project, and has not yet created a single ticket with the problem of access to the system.
Thank you in advance.
Source: https://habr.com/ru/post/245903/
All Articles