How to strengthen the protection of passwords of “12345” from brute-force attack

Object: Web login form.
Given task: to strengthen the protection of the user’s account from the selection of a simple password to his account, using a minimum of resources.

What is the minimum of resources? It does not use a table-reference to block by IP-address and User-Agent. Do not use unnecessary requests to the system; do not clutter up the system with unnecessary authorization cycles.

And, to do the magic requirement — even if the bot will enter the required username and password… do not let him enter, but the real user to let.

Is it possible to do that? In theory, of course not. But in practice, and in private, under certain conditions, it proved to be quite possible.
Welcome under cut for details.

So, let’s assume that our user has login “test” and password “12345”. Vile bot has connected dictionary-generated passwords and are ready to work at a speed of 700 passwords per second. It knows that the login user is “test”. Situation breath-taking: the password “12345” will be calculated over very small time. The user, meanwhile, opened the website and started to enter the username and password in a web form login.

Let’s make changes in the authorization system, while none of them has started its work, and the trouble has not yet happened.

Magic will be in the third variable to be “glued” to the login-password pair. I called her touch.

Every time someone gets (attention: gets, not ask!) the login and password, the date “touch” for user “test” is updated to the current date-time:

login/password/touch: 'test', '12345', '2014-12-13 14:00:00'.

Suppose that the bot is started the first iteration and was offered the password “1” for login “test” ‘2014-12-13 15:00:00’. Triggered the login_check controller that reads from the database a couple of login and password that no one “touched” as much as 2 seconds! Where do these 2 seconds?! About it further.

Such a pair of login and password is found. The difference between the last «touch» and the current time – 1 hour. So record successfully returned to our request.

First login-password pair are matched and login_check concludes that «test / 12345″ is not equal to «test / 1.” The controller returns «auth error». And then the date «touch» for user «test» is updated to the current: “13/12/2014 15:00:00”.

The bot proceeds to the next iteration: tries the password “2”.

The speed of a bot is measured by microseconds. It tries to log in immediately: in the ’13/12/2014 15:00:00 “.

And here comes into play our algorithm – a condition for the parameter «touch» is not already running. 2 seconds have not yet passed. Fail.

Modified by our logic controller «login_check» cannot get a couple of login and password.

The record exists, but its date of “touch,” is too “fresh”.

And it is not part of the sample. And if such pair of login and password is not present, then the controller will respond to the bot “auth error”.

The bot does not give up, continues to guess, and finally comes to a correct password “12345”.

The probability that it is current attempt will return success – and is extremely small. 1/700 for each login attempt! That is, if earlier it was 1:1, now 1:700. And the faster bot is, the more likely that it is waiting for fail.

As a result, only a very small part of the password will be really checked. The rest will get false positives, even if they are correct.

What about the user?

Let’s start with the user. The user, in contrast to the bot enters data into a web form by hands across the keyboard and watching the visual organs on the monitor. And the flexibility of its algorithmic abilities much better than the bot. In fact, the user in some way artificial intelligence. So, part of the logic is already in it. And we’re going to use it!

When the user sees the authorization error, he often rewrites the password again. Even if he just enter the password himself. Even if the password is filled automatically from password manager. I did this even before I applied system of protection of simple passwords.

Yes, I promised to tell you about two seconds. I am telling:

Two seconds is the optimum time for which the user carries out operations on data correction and makes the following login attempt. In those two seconds the user completely fits. If the user does not have time – he can always try again and this time the operation touch is probably already canceled.

In conclusion.

What happens if the bot will know about a 2-second delay? If we apply our test data, this means that the efficiency of the bot will decrease: only 1 attempt to crack the password instead of 1400.

P. S. I’d like to hear the criticism because the system is already implemented in one project and have not yet created any ticket with the problem of access to the system.

Thanks in advance.

The main disadvantage of this method is the ability to block the bot authorization for the user whose account is trying to crack. In the activity of the bot the user will see the same error log and the author assumes the user is accessing tech support with the question of authorization.

About the CleanTalk service

CleanTalk is a cloud service to protect websites from spam bots. CleanTalk uses protection methods that are invisible to the visitors of the website. This allows you to abandon the methods of protection that require the user to prove that he is a human (captcha, question-answer etc.).

This text is a translation of the article “Как усилить защиту паролей «12345» от brute-force атаки”  published by Дмитрий on habrahabr.ru.