How to deal with brute force?

JackShcherbakov2019-05-14 19:40:28

Information Security

JackShcherbakov, 2019-05-14 19:40:28

Hello!
Let's say there is a login form on the site. How to make protection against brute better?
I thought about it and decided to do this:
1) Remember the user's IP
2) After 3 incorrect attempts, we make a delay to enter from this IP in 30 seconds
4) After subsequent attempts, the delay doubles
5) We send a notification to the user about an attempt to enter his
account note that the delay is activated for this particular IP. That is, if an attacker tries to pick up a password, he will not succeed, because there will be crazy delays. At the same time, the account owner will be able to easily log into the account and see that someone tried to log into the account.
Normal option? What do you think? Are there better ways?
Of course, ideally, this is an SMS login, but this option has not yet been considered.
Thanks in advance to everyone who helps!

Answer the question

In order to leave comments, you need to log in

11 answer(s)

Vladimir Dubrovin, 2019-05-14
@z3apa3a

It all depends on what kind of service you are developing, how and by whom it will be used, and what is interesting in it for a brute-forcer. As long as your service does not have a large user base and is not particularly interesting to attackers and only standard crawler bots looking for message boards brute it, anything will work, including simple rate limits, as you suggest and captchas. If you have a popular service with a large and diverse user base, then it turns out that both good and bad users can go from one IP, in addition to direct brute (by password), there is a reverse one (with one password for different users), that users really do not like captchas (and sometimes they are not physically able to enter them, for example, due to poor eyesight or color blindness), etc.

Sergey Kotov, 2019-05-14
@liqrizz

create your own unique captcha

Stalker_RED, 2019-05-14
@Stalker_RED

Add a csrf token to the form to restrict xss and you can't just spam post requests without first getting the form.
In addition to the delay, you can also show captcha.
A delay of 30 seconds from the very start is a bit too much, because. three mistakes are not difficult to make by hand (wrong layout, caps lock). I would start with ten, for example.
The attempt counter is not only for ip but also for login, because they can brute the target user from different ip.
In general, yes, you are reinventing something that has long existed both at the level of methodology and in the form of software products.

rogiivs, 2019-05-14
@rogiivs

Why would you give 30 seconds of overexposure? just send a recovery letter to the mail and that's it, with a warning type, if it was not you, change the password to a more complex one. Or just create session statistics on the site for users. and issue a token for each authorization.

Vladimir Kuts, 2019-05-14
@fox_12

fail2ban

MoksS, 2019-05-15
@MoksS

Alternatively, if you register by mail, then after several unsuccessful attempts to enter the site, send the user a notification by mail, then freeze the account / change the password, or just a link so that the user can log in again and give new cookies / token. People suggested putting the captcha higher, even if it does, there will still be an extra barrier, and not everyone wants to fight it and spend time on it.

Alexey Stupenkov, 2019-05-15
@alexstup

Make brute force expensive and unprofitable for the attacker. For example, calculate something tricky in a couple of seconds in javascript and use it in an input form.

d-stream, 2019-05-15
@d-stream

Please note that the delay is activated for this particular IP. That is, if an attacker tries to pick up a password, he will not succeed, because there will be crazy delays. At the same time, the account owner will be able to easily log into the account and see that someone tried to log into the account.

Modern bots scan from a fairly large range of addresses (for example, a botnet) and, accordingly, there will be only one hit in the logs ...

Evgeny Oksenchuk, 2019-05-14
@Yevhen89

as an option, if from hacking applications, you can set input type = "hidden", the real user will not see this field, but the application will write there, and if there is something there, then immediately block it, this is another option from hacking

Eugene Pedya, 2019-05-23
@fpinger

Decide on areas of responsibility.
Admin is one thing, public access is another.
Decide on the password requirements and limit access to the admin panel only from certain IPs.
Next, clearly let the user know that his password is his responsibility.
Add two factor authentication.
If they start to break, then brute force is only one of the approaches.