Your message dated Mon, 20 Jan 2025 15:15:18 -0700
with message-id <[email protected]>
and subject line Not making a change
has caused the Debian Bug report #1066979,
regarding common-auth: sudo should not have incorrect password delay
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1066979: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066979
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libpam-runtime
Version: 1.5.2-6+rpt2+deb12u1
Severity: normal
File: common-auth
X-Debbugs-Cc: [email protected]
Dear Maintainer,
By default, on Debian and derivatives, `sudo` has a ~2 second delay for
incorrect password attempts. This serves no security purpose whatsoever and
merely annoys the user.
I think it would be great if it could be removed. Unfortunately it's not super
simple because you do want a delay from other authentication clients (sshd,
etc.), and they all use /etc/pam.d/auth-common, so you can't just add `nodelay`
to `pam_unix.so` in that file.
I can think of a few solutions, but I'm not super familiar with Debian's PAM
system (especially `pam-auth-update`). Anyway:
1. Add `auth-common-nodelay` that's exactly the same as `auth-common` but with
`nodelay`, and use that from `/etc/pam.d/sudo[-i]`.
2. Add `nodelay` in `auth-common` and then add `auth-delay` that uses
`pam_faildelay.so` to add a delay. The `@include auth-delay` from all files
*except* `sudo[-i]`.
3. Improve `pam_faillock.so` to support exponential delays. The use of
exponential delays is a very obvious feature and surprising omission. I assume
the delay was originally fixed because of PAM's weird architecture that makes
stateless authentication easier. However `pam_faillock.so` is stateful and
records failed authentication attempts so the hard work has already been done.
Modifying it to have an exponential delay (0, 0, 0, 0, 0, 1, 2, 2, 5, 10s, ...)
would be quite easy.
I think 3 would be the best solution but is probably a fair bit of work. I'm
not sure 2 is a great option because it isn't fail-safe. 1 is probably a
reasonable option.
Also, a 2 second delay may sound insignificant but think how many people in the
world use sudo. It's a minor annoyance multiplied by millions.
Cheers,
Tim
-- System Information:
Debian Release: 12.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf
Kernel: Linux 6.1.0-rpi7-rpi-v8 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libpam-runtime depends on:
ii debconf [debconf-2.0] 1.5.82
ii libpam-modules 1.5.2-6+rpt2+deb12u1
libpam-runtime recommends no packages.
libpam-runtime suggests no packages.
-- debconf information:
libpam-runtime/profiles: unix, systemd, chksshpwd
libpam-runtime/override: false
libpam-runtime/conflicts:
libpam-runtime/no_profiles_chosen:
libpam-runtime/title:
--- End Message ---
--- Begin Message ---
control: tags -1 wontfix
As discussed in my previous mail, I do think there is a potential
security delay and there are cases for example with a compromised ssh
private key but no compromised password where sudo could be a password
guessing oracle. In such a case, there is a security benefit.
Regardless, I think that finding a solution to fix this while allowing
sudo to use common-auth is more trouble than it is worth.
--- End Message ---
