The account with no password
A locked account and an account with an empty password look similar in a listing and are not the same thing. Filtering the shadow file on an empty second field finds the difference: the raw line shows two colons with nothing between them where every other account carries a hash, and the status command reports NP for no password while everything else reports L for locked. Whether that is exploitable depends on the authentication stack, and on a stock Debian install /etc/pam.d/common-auth carries nullok, which tells the password module to accept an empty password. Remote logins over SSH still refuse empty passwords by default, so this is a local door rather than a remote one - but it is a door, and it is not usually there on purpose.
This account has no password. Not a locked one. None.
A locked account and an account with an empty password look similar in a listing, and they are not the same thing at all.
Filter the shadow file on the password field being empty, and one line comes back. It shows two colons with nothing between them, where every other account on the machine carries a hash.
The status command spells it out: no password. Ask about any other account and it reports locked instead.
Whether that matters depends on how the system is configured to check passwords, and here the module is set to accept an empty one.
Remote logins still refuse it by default, so this is a local door rather than an open one. It is still a door, and nobody meant to leave it there.
Filter your shadow file on the password field. It should return nothing.
#linux#security#selfhosted#infosec#sysadmin
❯ Filter your shadow file on the password field. It should return nothing.