December 15, 2014 at 18:10How to strengthen password protection of “12345” from brute-force attack
Object: web login form.
The task is given: to strengthen the protection of the user's account from the selection of a simple password to his account using a minimum of funds.
What is a minimum of funds? It does not use reference tables to block by IP address and User-Agent. Do not use extra 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.
Can this be done? In theory, of course not. But in practice, in private and under certain conditions, as it turned out, it is very possible.
I invite you to cat for details.
So, suppose that our user’s login is “test” and the password is “12345”. The vile 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 user login is “test”. The situation is awful: 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 login web form.
Let's make changes to the authorization system, until none of them has started its work, and there has been a disaster.
The magic will be in the third variable, which should be “glued” to the login-password pair. I called her touch .
Every time someone receives (attention: receives, but doesn’t ask!) login password, date “touch” for user “test” is updated to the current date-time:
Suppose the bot starts the first iteration and offers the password “1” for the login “test” at '2014-12-13 15:00:00'. The login_check controller is working, which reads a login-password pair from the database that no one "touched" for 2 whole seconds! Where did these 2 seconds come from ?! This will be further.
Such a login-password pair is located. The difference between the last “touch” and the current time is 1 hour. Therefore, the record is successfully returned 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 an "auth error". And then the “touch” date for the user “test” is updated to the current: '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 tries to log in immediately: at '2014-12-13 15:00:00'.
And here our algorithm comes into effect - 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 she does not fall into the sample. And since there is no such login-password pair, the controller will reply to the auth error bot.
The bot does not give up, continues the selection and, finally, comes to the correct password “12345”.
The likelihood that it is the current attempt that will return success is extremely and extremely small. 1/700 for every login attempt! That is, if it used to be 1: 1, now it is 1: 700. And the faster the bot, the more likely it will fail.
As a result, only a very small part of the passwords will be truly verified. The rest will receive false positives, even if they are true.
And what is the user?
Let's start with the user. The user, unlike the bot, enters data into the web form with his hands through the keyboard and looks at the monitor with his visual organs. And the flexibility of its algorithmic abilities is much better than the bot. In fact, the user is in some way 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 he just entered the password himself. Even if the password is set up automatically from password-manager. I did this even before I applied my simple password protection system.
Yes, I promised to talk about two seconds. I tell:
Two seconds is the optimal time for which the user carries out data correction operations and makes the next login attempt. In these two seconds, the user fits completely. If the user doesn’t meet it, he can always try again and during this time the touch action will probably be canceled.
Finally.
What happens if the bot finds out about the 2 second delay? If we apply our test data, this means that the efficiency of the bot will decrease: only 1 attempt to guess the password instead of 1400.
PS I'd like to hear criticism, because the system has already been implemented in one project, and has not yet created a single ticket with a problem accessing the system.
Thanks in advance.
The task is given: to strengthen the protection of the user's account from the selection of a simple password to his account using a minimum of funds.
What is a minimum of funds? It does not use reference tables to block by IP address and User-Agent. Do not use extra 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.
Can this be done? In theory, of course not. But in practice, in private and under certain conditions, as it turned out, it is very possible.
I invite you to cat for details.
So, suppose that our user’s login is “test” and the password is “12345”. The vile 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 user login is “test”. The situation is awful: 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 login web form.
Let's make changes to the authorization system, until none of them has started its work, and there has been a disaster.
The magic will be in the third variable, which should be “glued” to the login-password pair. I called her touch .
Every time someone receives (attention: receives, but doesn’t ask!) login password, date “touch” for user “test” is updated to the current date-time:
login/password/touch: 'test', '12345', '2014-12-13 14:00:00'.Suppose the bot starts the first iteration and offers the password “1” for the login “test” at '2014-12-13 15:00:00'. The login_check controller is working, which reads a login-password pair from the database that no one "touched" for 2 whole seconds! Where did these 2 seconds come from ?! This will be further.
Such a login-password pair is located. The difference between the last “touch” and the current time is 1 hour. Therefore, the record is successfully returned 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 an "auth error". And then the “touch” date for the user “test” is updated to the current: '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 tries to log in immediately: at '2014-12-13 15:00:00'.
And here our algorithm comes into effect - 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 she does not fall into the sample. And since there is no such login-password pair, the controller will reply to the auth error bot.
The bot does not give up, continues the selection and, finally, comes to the correct password “12345”.
The likelihood that it is the current attempt that will return success is extremely and extremely small. 1/700 for every login attempt! That is, if it used to be 1: 1, now it is 1: 700. And the faster the bot, the more likely it will fail.
As a result, only a very small part of the passwords will be truly verified. The rest will receive false positives, even if they are true.
And what is the user?
Let's start with the user. The user, unlike the bot, enters data into the web form with his hands through the keyboard and looks at the monitor with his visual organs. And the flexibility of its algorithmic abilities is much better than the bot. In fact, the user is in some way 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 he just entered the password himself. Even if the password is set up automatically from password-manager. I did this even before I applied my simple password protection system.
Yes, I promised to talk about two seconds. I tell:
Two seconds is the optimal time for which the user carries out data correction operations and makes the next login attempt. In these two seconds, the user fits completely. If the user doesn’t meet it, he can always try again and during this time the touch action will probably be canceled.
Finally.
What happens if the bot finds out about the 2 second delay? If we apply our test data, this means that the efficiency of the bot will decrease: only 1 attempt to guess the password instead of 1400.
PS I'd like to hear criticism, because the system has already been implemented in one project, and has not yet created a single ticket with a problem accessing the system.
Thanks in advance.