/etc/shadow

/etc/shadow stores protected local password-hash and password-aging fields. Separating these values from the generally readable /etc/passwd database reduces exposure to offline password-guessing attacks.

Protecting Shadow Data

Passwords are not stored reversibly “encrypted” for later display. A local password entry normally contains a one-way password hash encoded with an algorithm identifier, salt, and parameters. An attacker who obtains hashes can guess candidate passwords offline, so the database should remain restricted.

Exact ownership and permission details vary, but access is commonly limited to root and narrowly authorized system components. Do not print, copy, log, or share shadow contents merely to inspect account status.

Reading the Nine-Field Format

A local shadow record contains nine colon-separated fields. A schematic record looks like this, with the hash deliberately omitted:

alice:<password-field>:20000:0:90:7:14:20500:

The fields are:

1. Login name.
2. Password hash or special password marker.
3. Last password change, in days since 1970-01-01; 0 requests a change at the next password-authenticated login in typical tooling.
4. Minimum password age, in days.
5. Maximum password age, in days.
6. Warning period before password expiration, in days.
7. Inactivity period after password expiration, in days.
8. Account expiration date, in days since 1970-01-01.
9. Reserved field.

Empty fields and special numeric values have defined meanings that can vary by field and tooling. Use account-management commands instead of editing values by sight.

Interpreting the Password Field Carefully

A valid hash in field 2 supports local Unix-password verification. A value beginning with ! commonly locks that password hash, while * or another invalid hash marker prevents successful password verification through that field. An empty value is security-sensitive and can allow passwordless behavior depending on PAM policy.

These markers describe the local password path, not every possible authentication method. SSH public keys, certificates, tokens, and application-specific credentials can remain usable unless separately restricted. Account expiration in field 8 is also distinct from password locking.

Distinguishing Password and Account Dates

Fields 3 through 7 concern password aging: when the password last changed, when another change is allowed, when it expires, when warnings begin, and how long after expiration password login remains available. Field 8 expires the account on an absolute day regardless of the password's age.

For example, a 90-day maximum password age is not the same as an account expiration date. The former moves relative to the last password change; the latter is a fixed date until an administrator changes it.

Inspecting and Changing Policy through Tools

Administrators should query only the information required for the task:

$ sudo passwd -S alice
$ sudo chage -l alice

passwd -S summarizes local password status, while chage -l lists aging information in a readable form. Output formats and authorization requirements can vary by distribution.

Use passwd, chage, usermod, and related account tools for changes. If manual repair of the local shadow database is unavoidable, vipw -s provides locking; validate account databases with pwck. Maintain a recovery session before remote authentication changes.

PAM and NSS can integrate authentication and identity sources beyond local shadow files. A system account may therefore have no local shadow record or may authenticate through additional services.

To practice account status and aging policy in a controlled environment, try these hands-on labs:

1. Manage Linux User Accounts with useradd, usermod, and userdel - Practice the complete lifecycle of user administration, from creating and securing new accounts with useradd and passwd to modifying and deleting them.
2. Configure User Accounts and Sudo Privileges in Linux - Learn essential techniques for managing user accounts and sudo privileges, including enforcing password policies and securing accounts.

Summary

You can now interpret shadow policy without exposing the complete password database.

1. Treat password hashes as restricted authentication material.
2. Read the nine shadow fields by purpose.
3. Distinguish password locking from disabling every login method.
4. Separate password aging from absolute account expiration.
5. Inspect and change policy through focused account tools.