It seems an offline attack against /etc/shadow is the more sensible option for the attacker as timeouts can be configured for “online” attampts on the same system.
Do you know how the contents of thatdir are encrypted?
For now it looks to me that offline attacks aren’t possible.
However, we need to know all vectors for “online” accounts, their timeouts, how much these can be parallelized (run su automated in different thousands of terminal-emulator tabs).
For usability a FED-quality password for root authentication is infeasible indeed. If we can answer this question and/or
exclude offline attacks, and increase difficulty for “online” attacks by increasing timeouts, there could even be secure relatively short linux user account passwords. If we could delay authentication attempts to being only possible once per X seconds, passwords might become short enough to have ok usability.
Configuring timeouts for “online” attempts requires root, which we assume the compromised user account does not yet have.
dir? /etc/shadow (contains passwords) isn’t encrypted but can only be accessed by root due to access rights.
Are there implications to the default use of md5?
I don’t think so. That only matters if /etc/shadow gets stolen, which requires root compromise. Such as a server which was once secure and later hacked should not let the attacker know the passwords of these users since users tend to re-use passwords. Therefore it’s best if any stored password is salted and hashed rather than in cleartext. As far as I understand this has nothing to do with “online” attacks from a compromised user account.
Much of the same logic behind using shorter passwords for online services and websites applies here because the attacker is limited to just a few guesses before a long time out (that we configure) as opposed to trillion or more guesses per second.
I’m guessing 4 dicewarewords are enough.
https://theintercept.com/2015/03/26/passphrases-can-memorize-attackers-cant-guess/
This will be implemented next. Rationale:
- preventing compromised user accounts (such as www-data) from bruteforcing other accounts
- short passwords secure against “online” attacks
Please suggest pam_tally2 vs pam_tally vs other pam lockout plugins.
Please also suggest defaults. After 5 or 10 failed login attempts, lock the account forever and require the user to boot into single user / recovery mode to unlock?
5 or 10 attempts are not enough for any reasonable burtefoce? Even a common word plus a few numbers would be secure enough?
If we want users to use strong passwords, we can use pam_cracklib to only allow passwords of a certain strength.
https://wiki.archlinux.org/index.php/Security#Enforcing_strong_passwords_using_pam_cracklib
We can also add a delay after a failed login attempt by using
auth optional pam_faildelay.so 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.
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.
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?
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.
Bug:
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_tally2pam_tally2 does not work with xscreensaver.
Contacted developer of xscreensaver:
https://www.whonix.org/pipermail/whonix-devel/2019-September/001439.html
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:
https://github.com/Whonix/security-misc/blob/master/usr/lib/security-misc/pam_tally2-info
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?
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.