How strong do linux user account passwords have to be when using Full Disk Encryption (FDE) too?

Question

Suppose a non-root user was compromised over remote by malware that is now using su (tty or similar) trying to login as root, trying every possible password by bruteforcing.

assume: full disk encryption with a strong passsword is in place.

goal: secure root account password.

non-goals: Protecting password from offline attacks when an attacker manages to steal /etc/shadow and to use offline attacks against it is out of scope.

In this situation...

Are offline attacks against linux user account passwords possible?

When are strong linux user account passwords required?

Are strong linux account passwords required?

How many password can an attacker try against linux user accounts per second or per minute?

Can passsword bruteforcing against linux user account passwords be parallelized by the attacker and is bruteforcing only bound by the attackers available resources of CPU/RAM/etc.?

Or is passsword bruteforcing against linux user account passwords limited by su/pam or something? Can only be a limited number of passwords per second or per minute be tested?

Can su/pam/everything be added a (longer and longer becoming) delay when trying a wrong password to slow down bruteforce attacks?

How many random characters or dice words must a linux user account password have to be very secure? Are these the same requirements as for very secure FDE passwords or lower due to offline attacks not being possible against linux user account passwords?

Answer 1

Let's assume three possible attack scenarios where the attacker is running a local process:

(1) The attacker exploits a privilege escalation vulnerability

In this circumstance, the attacker can change their UID on their own. They don't need to brute force any password. The best defense against this is to have a hardened, up-to-date system.

(2) The attacker has access to the password hashes

If the attacker can read the password hashes directly, either because they've exploited a bug that allows them to read /etc/shadow (or a vulnerable process that has access to it), or because they are attacking an outdated system that still keeps passwords in the world-readable /etc/passwd, then they'll be able to perform an offline brute force attack. They could either perform the attack on the victim system, or transmit the hashes to a more powerful system (or cluster) to offload power.

Protecting against this requires using a strong password, as they will be able to authenticate as soon as they calculate the correct password. The password can be further strengthened by using multiple rounds of hashing. This can be configured with the pam_unix(8) option rounds=n.

You can additionally enforce a strict password expiration policy. This is one of the few circumstances in which such a thing would actually be warranted and is not security theater. It would allow for slightly weaker passwords to be used safely. If a password takes on average 2 years to break, it would be considered very weak. If the password is changed every month, the attacker will be wasting a lot of time trying to break a password that will no longer be valid by the time they crack it.

(3) The attacker is in %wheel or otherwise is permitted to use su

In this case, all the attacker can do is perform an online brute force attack. They will be limited by the number of concurrent processes they can spawn, as well as the artificial delay imposed by each login process. For su, this can be configured by setting the FAIL_DELAY variable in login.defs(5). If the system is using PAM, the pam_fail_delay(3) module can be used instead.

The password does not need to be nearly as strong in this case. Assuming each su invocation takes 3 seconds for a passphrase and the attacker is running 10,000 concurrent processes, they're still only limited to 30,000 passwords per second. A 7 character alphanumeric passphrase would hold up for one year on average, which is more than enough time to stop the attack, assuming you check your logs more than once a year. A system with 10,000 su processes all failing is very noisy...