[TUHS] Questions about * and ! in the password field of passwd and shadow

[Ron Natalie via TUHS]

I was going way back before System V.   We moved our passwords out of 
public  view in /etc/passwd back in our version 6 variants.
Yes, * worked fine because it could never match the encrypted password.

The V6 manual doesn’t mention this “hack.”   It still talks about GCOS 
(which is where most people had started putting information like the 
user’s real name.

Amusingly at BRL, we put the user name in an email-complaint format such 
as:

ron::58:33:Ron Natalie <ron>:/sys1/ron:

This bit one of our admins once.   He wanted to find his entry in the 
file and typed:

grep <howard> /etc/passwd

Alas, he was root at the time.



------ Original Message ------
>From "segaloco via TUHS" <tuhs at tuhs.org>
To "The Eunuchs Hysterical Society" <tuhs at tuhs.org>
Date 1/7/2026 4:13:39 PM
Subject [TUHS] Re: Questions about * and ! in the password field of 
passwd and shadow

>On Wednesday, January 7th, 2026 at 11:40, Ron Natalie via TUHS <tuhs at tuhs.org> wrote:
>
>>  Back when the (encrypted) passwords were in /etc/password, a * was a
>>  common way to make accounts that could not be logged into. This goes
>>  back forwever (putting a blank password field in just meant there was no
>>  password required to log in). This predated /etc/shaddow and even the
>>  inclusion of the “salt” characters at the beginning of the passwords.
>>  The ! to disable wasn’t something I saw. It must have come later (but
>>  before people started using programs to manipulate these things).
>
>The passwd(5) (or 4 for USG stream) manpage should give some pointers.
>As of the initial System V release (pre shadow), the only defined
>behaviors of this field are either an encrypted (via crypt(3)) string
>or an empty (null) string for no password.  Additionally, a password can
>be followed by a comma and then aging information.  I don't see any
>explicit handling of * or !.  Presumably using * just means that the
>expected output of crypt(3) is *, an unlikely if not impossible
>scenario, leading to the behavior of no login available.
>
>I'll have to check the passwd(4) page in my SVR4 manuals at home.  In
>any case, that's where I'd suggest looking.  If it's not in the manuals,
>it may qualify as unintended behavior or something like that, meaning
>even if there is any handling for these characters specially (which I
>couldn't find in login(1), su(1), or any of the libc passwd stuff), that
>handling was never publicized.
>
>- Matt G.