Limiting number of combo attempts with Fail2ban and 128 bits of entropy

Question

Apps such as Fail2ban and DenyHosts enable unix administrators to limit username/password combo attempts to typically 3 attempts. But why 3? Some admins enable more, like 6 or 8 giving honest users a little more slack when making different attempts at a password they may not recall exactly. But why not 18? Or even 30?

If a sophisticated cracker wanted to brute force a combo with a scheme involving 128 bits of entropy, s/he would need to make trillions of attempts a second. So if an admin limited the total number of attempts to 100 using Fail2ban, wouldn’t the authentication system still be secure and robust, as long as the admin sets up their username/password scheme to require 128 bits of entropy?

Answer 1

You can set any value you want. See parameter maxretry in jail.conf.

You are right. Giving 100 attempts before blocking means that an attacker can try about 7 bits (log 100). Thus remaining will be 121 bits, which means very low probability to guess the password.

On the other hand, why would one want to give an attacker more chances to guess the password?

If you ban the attacker, he will need another IP to continue his attempts. If you ban the attacker after 5 attempts, it means he will need 20 times more different IPs than in the case with allowed 100 attempts. For the most of the single working attackers this is an essential increase of resources. They will stop the attempts.

One more aspect is your resources. Each login attempt means that your server needs resources (CPU, memory) to establish a connection, session, to check the password. In for a small number of attackers like 5-10 it will not affect other processes on your server. But if there are thousands of login requests from different IPs, this can require a lot of resources from your server. Thus the processes running on it can be slowed down. That's why it makes a difference, if you ban an attacker after 3-5 attempts or after 100 attempts.