Debian 12 CIS 5.4.1.4: set_password_hashing_algorithm_logindefs fails ENCRYPT_METHOD SHA512, although the control allows SHA512 or YESCRYPT #15151

Description of problem:

Found while comparing CIS results on Debian 12 images.

• Product: debian12
• Profiles: cis_level1_server, cis_level1_workstation, cis_level2_server, cis_level2_workstation, control 5.4.1.4 "Ensure strong password hashing algorithm is configured"
• Rule: set_password_hashing_algorithm_logindefs, variable var_password_hashing_algorithm

controls/cis_debian12.yml 5.4.1.4 selects var_password_hashing_algorithm=yescrypt, and its note says the rule allows either SHA512 or YESCRYPT (L2102-L2111 at v0.1.82, same on master). The yescrypt selector is YESCRYPT alone (var_password_hashing_algorithm.var L15-L25), and the OVAL pattern-matches the ENCRYPT_METHOD value against the variable (oval/shared.xml L24-L35), so only YESCRYPT passes.

Debian 12's login package (1:4.13+dfsg1-1+deb12u2) ships /etc/login.defs with ENCRYPT_METHOD SHA512, so a default Debian 12 system fails 5.4.1.4 although the control, per the note, accepts SHA512.

The same note is in two other control files, and both implement it with a two-value selector:

• Ubuntu 22.04: cis_ubuntu2204 = SHA512|YESCRYPT (cis_ubuntu2204.yml L2046-L2055, [Ubuntu] Create new value for var_password_hashing_algorithm #13949)
• Ubuntu 24.04: cis_ubuntu2404 = SHA512|YESCRYPT (cis_ubuntu2404.yml L2127-L2136, U2404 5414 #12636)

Debian 13 has the same control with cis_debian13 = YESCRYPT|SHA512 (cis_debian13.yml L2248-L2255 on master), added for 5.4.1.4 by commit 52c2bd3 in #14851. Debian 12 still has the yescrypt selection from #13712, which added the benchmark.

SCAP Security Guide Version:

0.1.82 (release data stream ssg-debian12-ds.xml from scap-security-guide-0.1.82.zip). The control entry and the variable are unchanged on master at f956856.

Operating System Version:

Debian 12.15: debian:12@sha256:f37a335e82bca302e955fa39f9dfe28f1be618f016f8a2b56318e5a5111afc26 (linux/amd64), login 1:4.13+dfsg1-1+deb12u2. OpenSCAP 1.4.4, oscap-chroot.

Steps to Reproduce:

The image's root filesystem is evaluated offline. The only changes to it are removing /.dockerenv and adding a stand-in linux-base entry to the dpkg database (a container export has no kernel package, and SSG evaluates most rules only on system_with_kernel).

1. Get the data stream:

   curl -fLO https://github.com/ComplianceAsCode/content/releases/download/v0.1.82/scap-security-guide-0.1.82.zip
   unzip scap-security-guide-0.1.82.zip scap-security-guide-0.1.82/ssg-debian12-ds.xml
   

2. Export the image's root filesystem and add the stand-in:

   mkdir root
   docker export "$(docker create --platform linux/amd64 debian:12@sha256:f37a335e82bca302e955fa39f9dfe28f1be618f016f8a2b56318e5a5111afc26)" | sudo tar -x -C root
   sudo rm -f root/.dockerenv
   printf '%s\n' '' 'Package: linux-base' 'Status: install ok installed' 'Priority: optional' 'Section: misc' \
     'Installed-Size: 1' 'Maintainer: test <test@example.invalid>' 'Architecture: all' 'Version: 0' \
     'Description: stand-in' | sudo tee -a root/var/lib/dpkg/status >/dev/null
   

3. Evaluate:

   grep '^ENCRYPT_METHOD' root/etc/login.defs
   sudo oscap-chroot root xccdf eval \
     --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
     --rule xccdf_org.ssgproject.content_rule_set_password_hashing_algorithm_logindefs \
     scap-security-guide-0.1.82/ssg-debian12-ds.xml
   

4. Set ENCRYPT_METHOD YESCRYPT in root/etc/login.defs and evaluate again.

Actual Results:

ENCRYPT_METHOD SHA512
Rule    xccdf_org.ssgproject.content_rule_set_password_hashing_algorithm_logindefs   Result  fail

With ENCRYPT_METHOD YESCRYPT the rule passes. In the data stream the four CIS profiles refine var_password_hashing_algorithm to selector yescrypt.

Expected Results:

The rule passes with ENCRYPT_METHOD SHA512 and with ENCRYPT_METHOD YESCRYPT, as the control note says.

Additional Information/Debugging Steps:

Suggested fix, the same as for Debian 13:

--- a/linux_os/guide/system/accounts/accounts-pam/var_password_hashing_algorithm.var
+++ b/linux_os/guide/system/accounts/accounts-pam/var_password_hashing_algorithm.var
@@ -22,5 +22,6 @@
     cis_rhel8: YESCRYPT|SHA512
     cis_rhel10: YESCRYPT|SHA512
     cis_fedora: YESCRYPT|SHA512
+    cis_debian12: YESCRYPT|SHA512
     cis_debian13: YESCRYPT|SHA512
 
--- a/controls/cis_debian12.yml
+++ b/controls/cis_debian12.yml
@@ -2106,7 +2106,7 @@
           - l1_workstation
       rules:
           - set_password_hashing_algorithm_logindefs
-          - var_password_hashing_algorithm=yescrypt
+          - var_password_hashing_algorithm=cis_debian12
       status: automated
       notes: Rule allows either SHA512 or YESCRYPT
 

The bash remediation takes the first value of a multi-value selector (bash/shared.sh L5-L7), so with YESCRYPT|SHA512 it keeps writing YESCRYPT. The debian12 ANSSI profiles also select yescrypt and are not touched by this change.

I built debian12 from master (f956856) with this change and evaluated the same image: the rule passes with SHA512 (the default file) and with YESCRYPT, and fails with SHA256. oscap ds sds-validate accepts the data stream.

Related, not checked against the benchmark text: for 5.3.3.4.3 ("Ensure pam_unix includes a strong password hashing algorithm") debian12 selects var_password_hashing_algorithm_pam=yescrypt (cis_debian12.yml L2051-L2059), while debian13 selects cis_debian13 (yescrypt|sha512) for the same control. The default Debian 12 PAM configuration uses yescrypt, so this one passes on a default system; if the Debian 12 benchmark accepts sha512 there as well, the same kind of change applies.