Attack surface · Lynis

The audit that checks the wrong algorithm

Published 2026-08-12 · HardStacked · 5 min

These commands are provided as is, without warranty. Test on a non critical machine or a snapshot first.

You run a Lynis audit on Debian 13, you get a decent hardening index, and this line stays:

lynis-report.dat

suggestion[]=AUTH-9230|Configure password hashing rounds in /etc/login.defs|-|-|

You open /etc/login.defs, you add the rounds every guide recommends, you rerun. The suggestion is gone. Except you just configured an algorithm your machine does not use, and your security did not move an inch.

Everything below comes from a real machine, a report dated 2026-08-12, Lynis 3.1.4 from the Debian repositories.

01. The two line verdict

The AUTH-9230 test never reads ENCRYPT_METHOD. It looks for SHA-crypt settings on a machine that hashes with yescrypt, does not find them, and takes points off.

The setting that actually governs your security is somewhere else, and Lynis does not look at it.

02. Does this apply to you? One command

bash

$ grep -E '^(ENCRYPT_METHOD|YESCRYPT_COST_FACTOR|SHA_CRYPT)' /etc/login.defs

Here is mine:

/etc/login.defs

ENCRYPT_METHOD YESCRYPT YESCRYPT_COST_FACTOR 8

If you see YESCRYPT, AUTH-9230 does not apply to you. That is the default on Debian 12 and 13, on recent Ubuntu, on Fedora and on Arch.

03. Why it happens

The test is shell, so you can read it yourself. On a Debian install it lives in /usr/share/lynis/include/tests_authentication, around line 353:

tests_authentication

# Test : AUTH-9230 # Description : Check password hashing rounds in login.defs if [ -f ${ROOTDIR}etc/login.defs ]; then PREQS_MET="YES"; fi SHA_CRYPT_MIN_ROUNDS_FIND=$(grep "^SHA_CRYPT_MIN_ROUNDS" .../login.defs ...) SHA_CRYPT_MAX_ROUNDS_FIND=$(grep "^SHA_CRYPT_MAX_ROUNDS" .../login.defs ...) if [ ${SHA_CRYPT_ROUNDS} -eq 0 ]; then ReportSuggestion "Configure password hashing rounds in /etc/login.defs" AddHP 0 2 fi

Its only precondition is that login.defs exists. Then it looks for two settings, SHA_CRYPT_MIN_ROUNDS and SHA_CRYPT_MAX_ROUNDS, and nothing else. The word ENCRYPT_METHOD does not appear anywhere in the test.

Those two settings only do something when ENCRYPT_METHOD is SHA256 or SHA512. With yescrypt, the equivalent knob is called YESCRYPT_COST_FACTOR. Two separate worlds, and the test only knows one of them.

04. The fix everyone recommends secures nothing

This is the part that matters. Add SHA_CRYPT_MIN_ROUNDS to your login.defs and the suggestion disappears, your index goes up by 2 points. Nothing else happens. Your passwords are hashed by yescrypt, which never reads that value.

You bought two points with zero protection. That is the definition of tuning a score instead of securing a machine, and it is the trap of every tool that hands out a grade.

If you want to genuinely harden hashing on a yescrypt machine, the cost factor is the knob. The default is 5. Mine is 8, and the file still carries the note I left back then:

/etc/login.defs

# Cout de calcul yescrypt (R1017, Lynis AUTH-9230). Defaut=5, durci a 8. # S applique aux PROCHAINS changements de mot de passe uniquement. YESCRYPT_COST_FACTOR 8

Read the second line: the new cost only applies to passwords changed after the edit. Existing hashes keep their old cost. If you raise this for real, change your passwords afterwards, otherwise you hardened the future and nothing else.

And note the irony: I had set this in response to AUTH-9230, correctly, and Lynis has asked me for it on every scan since.

05. How to judge any suggestion, without taking my word for it

The same report holds two suggestions with nearly identical wording:

lynis-report.dat

suggestion[]=USB-1000|Disable drivers like USB storage when not used, ... suggestion[]=STRG-1846|Disable drivers like firewire storage when not used, ...

Same sentence, same logic, same tool. One is relevant, the other is empty. The difference is not visible in the report, it is visible on the machine:

bash

$ modinfo usb_storage 2>&1 | head -2 ; modinfo firewire_core 2>&1 | head -2

modinfo

name: usb_storage filename: (builtin) modinfo: ERROR: Module firewire_core not found.

The USB driver is built into the kernel: the suggestion is arguable, and worth arguing about. The firewire driver exists neither as a module nor built in, on this kernel: Lynis is offering to disable something that is not there.

bash

$ grep -c firewire /lib/modules/$(uname -r)/modules.builtin

Zero. The driver is nowhere.

That is the method, and it works on any line of your report: before applying a suggestion, check that the thing it talks about exists on your machine.

06. Two more, on the same machine

The legal banner. Lynis asks for a legal warning in /etc/issue. Mine has had a complete one for months:

/etc/issue

ATTENTION: Acces reserve aux utilisateurs autorises uniquement. Toute activite est susceptible detre journalisee et surveillee. Tout acces non autorise est interdit et fera lobjet de poursuites.

The file is 195 bytes. The test looks for English phrasing. A perfectly valid banner, written in another language, counts as missing.

fail2ban. Lynis suggests installing it to ban hosts that pile up authentication failures. On this machine there is no inbound authentication service at all:

bash

$ ss -ltn | grep -c ':22 '

Zero. Without an exposed service, failed password attempts are local, the journal carries no source address, and fail2ban has literally nobody to ban. It would sit there installed, running, and inert. If you do have a real SSH server the suggestion is a good one, but it comes with a trap of its own: fail2ban can report a ban while blocking nothing.

07. What to take away, and what this does not say

Lynis is still a good tool. It found real things on this machine, and the index went from 63 to 80 by following its advice. The problem is not the tool, it is treating a suggestion as an instruction.

One word on scope: I am describing Lynis 3.1.4, not Lynis in general. Check yours before concluding anything:

bash

$ lynis --version

The behaviour of the test is readable in its own code, on your machine, at the path given above. That is the one source that does not go stale.

If your report holds dozens of suggestions and you cannot tell which ones matter, the triage takes longer than the audit. That is exactly the work we do.