Quick Answer: In
/etc/passwd, an asterisk (*) in the password field marks an account that can't log in with a password. No password hashes to a*, so the field works as a permanent lock. Bill Joy put one on thedaemonaccount in 3BSD in 1980, and Unix still uses the same convention today.
Here's a detail that surprises most people who open /etc/passwd for the first time. Early Unix stored every user's password hash in a file that any account on the system could read. The hash sat right next to the username, and the file was world-readable. The sentinel that protected the system's service accounts was one character: *. Understanding why that character works tells you a lot about how Unix login was designed, and why it still matters when you're locking down a server.
What the Asterisk Actually Does
The traditional /etc/passwd format has seven colon-separated fields. The second one holds the password hash, produced by the crypt(3) function. Login takes whatever password you type, runs it through crypt(3) with the stored salt, and compares the result to the stored string. If they match, you're in.
A * is not a valid output of crypt(3). So no typed password, however clever, can ever produce a match. The account is locked against password login, but the entry still exists. That's the whole trick. You don't need a separate "disabled" flag. You just put a value in the field that the comparison can never hit.
The source material here is a 3BSD /etc/passwd from 1980, preserved in Diomidis Spinellis's unix-history-repo. The daemon account, which owns background services, has a * in the hash field. Nobody is supposed to log in as daemon, so the asterisk makes that explicit at the file level.
The Real Name Field Was Already a Joke
The same file has the real-name field (the fifth one, often called the GECOS field) filled in with "the devil himself" for an account. Unix has always had a small streak of humor in its admin conventions, and the GECOS field was one of the few places where a sysadmin could leave a personal note. Plenty of early systems used it for phone numbers, office locations, or nicknames. Nobody was thinking about security audits when they wrote it.
That's worth remembering. The early design trusted users more than modern threat models do, and that trust shaped every field in the file.
Why the Hash Was Readable in the First Place
Here's what most introductory guides skip: making /etc/passwd world-readable wasn't careless in 1980. Programs like ls need to map numeric user IDs to names, and login needs the file to verify passwords. The design assumed hashes were strong enough that exposure wouldn't matter much.
That assumption aged badly. crypt(3) in its original form used DES, and modern GPUs can test billions of guesses per second against weak DES-based hashes. A world-readable hash file became an offline cracking target for anyone with a shell. That's why systems moved to shadow password files.
Shadow password files split the hashes into /etc/shadow, readable only by root, while /etc/passwd kept the public account metadata. On Linux, the shadow file uses the same sentinel convention. Most distributions' /etc/shadow entries for system accounts carry * or ! in the password field, and the passwd(5) man page documents the behavior.
The Counter-Intuitive Part: The Asterisk Isn't Encryption
Most people assume a password field with * means the password is "hidden" or "encrypted." It isn't. The * is a sentinel, not a hash. It means "this value will never match," and that's a different property.
This matters in practice. The common advice is "a locked account is secure because nobody can type its password." That's incomplete. A locked password field stops password login only. Other paths can still reach the account:
- SSH key authentication can work for an account with a locked password, depending on
sshd_configand whether the key is in~/.ssh/authorized_keys. sufrom root doesn't check the password of the target account in most configurations, so root can switch into it anyway.- Cron and service accounts may run processes under that identity regardless of the password field.
So a * is a good default for accounts that should never be interactive, but it's not a complete lockdown. If you need a real block, you also control the shell (/usr/sbin/nologin or /bin/false) and check authorized_keys.
Locking Accounts Today: What to Use
Modern tooling handles this more explicitly than the raw file does. Here's a practical comparison:
| Method | Effect on password login | Blocks SSH keys? | Best use |
|---|---|---|---|
* in /etc/shadow | Blocks (no hash matches) | No | Legacy system accounts |
! prefix on hash (passwd -l) | Blocks; old hash preserved | No | Temporarily locking a user |
Shell set to /usr/sbin/nologin | Blocks interactive shell | Yes, for shell logins | Service and daemon accounts |
usermod -e (expire date) | Blocks all logins after date | Yes | Contractors, offboarding |
The passwd -l method is the one most admins reach for. It prepends ! to the hash, so the original hash is preserved and passwd -u can restore it. The * approach doesn't keep the hash, which is why you can't simply unlock it later without setting a new password.
Where Most Admins Go Wrong
Here's where it gets practical. The biggest mistake is assuming * and ! are interchangeable. On some systems they behave slightly differently in /etc/shadow tools, and a script that checks for ! might miss a * entry, or the reverse. Audit scripts should match both.
Second, don't rely on the password field alone to protect a service account. Check the login shell and authorized_keys too. A daemon account with a * hash but a working /bin/bash shell is a classic audit finding.
Third, if you're maintaining a legacy system, /etc/passwd might still contain hashes instead of x placeholders. That means shadow passwords aren't enabled. Fix that before anything else. Run pwck to check the password files, and then migrate.
Frequently Asked Questions
What does an asterisk in etc passwd mean?
An asterisk in the password field means the account can't log in with a password. crypt(3) never produces a * as output, so no typed password can match. The account still exists and can own files or run services. It's a sentinel for "locked," and it has been used this way since early BSD releases.
How do I lock a user account on Linux?
Run sudo passwd -l username to lock the account. This prepends ! to the stored hash, so the password can't match. To undo it, run sudo passwd -u username. For a stronger block, also set the login shell to /usr/sbin/nologin, since SSH key logins can still work with only the password locked.
Why does etc passwd have an asterisk for daemon?
The daemon account runs background services and isn't meant for human login. Bill Joy's 3BSD file put a * in its password field so no one could log in as it with a password. The convention survives in modern systems, where /etc/shadow uses * or ! for accounts like daemon, bin, and nobody.
Is it safe to leave password hashes in etc passwd?
No. Hashes in /etc/passwd are readable by every local user, which makes offline cracking easy. Modern systems use shadow files, where /etc/shadow is readable only by root. If you see hashes in /etc/passwd on a current system, check whether shadow passwords are disabled and fix it.
Lock down your service accounts this week. Run grep -E '^[^:]+:[*!]' /etc/shadow on a server you manage, then check each locked account's login shell with getent passwd. If a locked account still has a real shell, change it to /usr/sbin/nologin. Pass this to whoever maintains your Unix boxes, because the etc passwd asterisk convention only protects you when the rest of the account is locked down too.