A clean implementation might require to config-package-dev displace /usr/share/pam-configs/unix. I don’t think it’s worth the risk of this implementation. All this does is better protect the hashed password in /etc/shadow from an attacker who got an offline copy of /etc/shadow and runs an offline cracking attack against it. Cases where this applies:
- someone not using full disk encryption (FDE) and /etc/shadow leaked
- broken FDE but no knowledge of root password (but also no longer by attacker required to view any file)
- an attacker who didn’t manage to get the root password through a keylogger (unrealistic since it assumes attacker can already read /etc/shadow)
- an attacker who thinks that the password used for linux user authentication is being used elsewhere and while having full disk access still wants to crack that password too
To add the delay against online bruteforcing we are better off using something like tally / tally2 as discussed here:
I will revert our current implementation.
After Appropriate place to ask questions on how Debian derivatives would best interact with Debian’s implementation of pam? was answered, I will ask how to cleanly implement this. Already prepared a draft for that:
How to append rounds=65536 in /etc/pam.d/common-password as a Debian derivative?
In /etc/pam.d/common-password we would like to change from
password [success=1 default=ignore] pam_unix.so obscure sha512
to
password [success=1 default=ignore] pam_unix.so obscure sha512 rounds=65536
How would we do that? Fork libpam-runtime and edit /usr/share/pam-configs/unix ? [1] [2] Or is there some more elegant solution using a /usr/share/pam-configs drop-in or so?
Kind regards,
Patrick[1]
dpkg -S /usr/share/pam-configs/unix
libpam-runtime: /usr/share/pam-configs/unix[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931994