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

[segaloco via TUHS]

On Wednesday, January 7th, 2026 at 14:43, Ron Natalie via TUHS <tuhs at tuhs.org> wrote:

> 
> This bit one of our admins once. He wanted to find his entry in the
> file and typed:
> 
> grep <howard> /etc/passwd
> 

My next door neighbors could probably hear how loud of a "oh nooooooo" I said reading that....

So SVR4 says:

> The password field consists of the character x.  This field remains only for
> compatibility reasons.  Password information is contained in the file
> /etc/shadow; see shadow(4).

Then in shadow(4) the password field is so described:

> A 13-character encrypted password for the user, 
> a lock string to indicate that the login is not accessible,
> or no string to show that there is no password for the login.

These lock strings are then things as described earlier in the thread like "*LK*" in the password field to indicate a lock.  Unfortunately I'm not quickly finding a list of known lock strings in the documentation, they can probably be found in the sources of the passwd(1) command if nothing else.

I also checked the 4.4BSD and Research V10 manuals, neither indicate anything other than an encrypted string or null can be used, the latter resulting in a password-less login.  No mention of special meaning in other characters.

I suspect if there ever was any difference between * and ! as representations of a special case, those may not have been all that widespread.  So all in all, the password field has formally accumulated the following features from what I can tell:

- encrypted string
- null (no password)
- comma plus aging info (USG stream)
- x (for shadow, later USG)
- *..* (later USG, .. includes "LK" for locked)

The consensus here thus far is that * (or !) were simply taking advantage of the fact that neither would be valid crypt(3) output so no user password should compare true.  I haven't come across any historic documentation describing these as having any special meaning otherwise.

- Matt G.