protect Linux user accounts against brute force attacks

If we want users to use strong passwords, we can use pam_cracklib to only allow passwords of a certain strength.

We can also add a delay after a failed login attempt by using

auth optional delay=4000000

Which will add a delay of 4000000 microseconds for every failed login.

I don’t see how it wouldn’t be. Unless the password is like a single character, I doubt the bruteforce would be finished within 5 attempts.

1 Like

Interesting to know these exist.

Well, when we allow only 5 wrong password entry attempts before requiring the user to boot into single user / recovery mode to remove the lock, we might not need to require the user to use a strong password. A minimum length of even lower case only 5 characters might be enough (or even overkill already)?

According to an online password cracking calculator, with 5 passwords per second, cracking a 5 character password would require 28 days. “passwords per second” - in our case it would be 5 passwords until unlocking using single user / recovery mode which would take the user probably several minutes figuring out. That’s 5-15 password entry attempts for the malware until the user hopefully got the hint.

A user who goes to single user / recovery mode over and over again until the malware brute forced the password is unlikely and couldn’t be helped.

In that scenario, which is hopefully realistic, pam_faildelay can’t add much too it? Perhaps that is a usability feature to prevent several failed password entry attempts in a row due to accidental wrong button press?


It might help slow down bruteforce attempts.

It’s meant to slow down bruteforce attempts.

1 Like

If we allow only 5 attempts before locking further attempts and reboot
to single user / recovery mode required, how would slowing down these 5
attempts help? Rather then exhausting these in 15 seconds it could take
60 or something seconds? Not a significant gain?

1 Like

It wouldn’t be that big of a gain. It would only help if the bruteforce will be over within a few attempts which is unlikely.

1 Like

A single failed password entry using sudo bash (or anything other than bash) currently causes two failed tally attempt. Can be seen under:

sudo pam_tally2
1 Like
1 Like

pam_tally2 does not work with xscreensaver.

Contacted developer of xscreensaver:

1 Like

Bruteforcing into linux user accounts is already severely limited

Quote security-misc:

  • Lock user accounts after 100 failed login attempts using pam_tally2. /usr/share/pam-configs/tally2-security-misc

This also has good usability:

This seems to function really well. To further increase resistance against linux user account burteforcing attempts, I am wondering if the current 100 maximum password entry attempts could be reduced to something lower. Perhaps 50 and later even lower if that works well too?

1 Like

We still need strong passwords. If the password is the default “changeme” then it isn’t going to be hard to bruteforce it even with pam_tally2.

1 Like

There are bad passwords, ok passwords, good passwords, strong passwords, very strong passwords.

With only 100 attempts for bruteforcing (soon less), we don’t need strong passwords. Not 20 characters alphanumeric with special characters.
example: “JX%q'\S+e1'D>Y,L4<uW” [1]

We might get away even with almost trivial passwords. This is fantastic for usability. Very, very few users realistically typing a password such a complicated password as [1].

I wouldn’t be surprised if most users keep the password changeme.
But we could do better on usability as for guiding the user to change the password form changeme to something else, warning if the password is still the default changeme and auto starting a GUI to ask for password change.

1 Like

Please review:


Looks good to me.

I experienced an issue with Whonix / Kicksecure pam_tally2 integration where failed (probably automated bot password cracking attempts) over POP3 (dovecot) lead to a user account getting locked.

For local user account login it is desirable to support short, unrackable passwords through limiting maximum password entries to a reasonable number (50 at time of writing). However, for e-mail login it cannot password cracking attempts cannot be effectively prevented. The only way to secure these is using the usually super long super complex passwords. Using keyfiles for POP3 login / SMPT is unfortunately very uncommon.

Failed POP3 (dovecot) logins should not result in linux user accounts getting locked.

I would advice to use different linux user accounts for server login and e-mail login. For example, user user for login and user mail for incoming mail.

Therefore I invented a script /usr/lib/security-misc/pam_tally2_not_if_x which in essence results in skipping checking pam_tally2 counter for a (currently hardcoded) list of exceptions.

Related files:

This results in file /etc/pam.d/common-auth to be injected with:

auth    [success=1 default=ignore] seteuid quiet /usr/lib/security-misc/pam_tally2_not_if_x
auth    requisite even_deny_root deny=50 onerr=fail audit debug

Causes confusing error message:

pam_exec(sudo:auth): /usr/lib/security-misc/pam_tally2_not_if_x failed: exit code 1

Reported upstream:

1 Like
1 Like