The /etc/shadow file is a core authentication component on Unix and Linux systems that stores encrypted passwords and related account metadata. Understanding its internal layout helps administrators troubleshoot access issues and secure user accounts effectively.
This article explains the essential structure, format fields, and practical implications of the shadow file for day-to-day system administration.
| Field | Position | Description | Example Value |
|---|---|---|---|
| username | 1 | Account login name, maps to the password hash | alice |
| password_hash | 2 | Encrypted password or status indicator like ! or * | $6$rounds=4096$salt$hashed... |
| last_password_change | 3 | Date of last password change as days since epoch | 19647 |
| min_age | 4 | Minimum days between password changes | 7 |
| max_age | 5 | Maximum password validity in days before forced change | 90 |
| warn_age | 6 | Days before expiration to warn the user | 14 |
| inactive_period | 7 | Days after expiration until account is disabled | 30 |
| expire_date | 8 | Absolute date when account becomes unusable, in days since epoch | 19999 |
| reserved_field | 9 | Currently unused, reserved for future use | 0 |
File Location and Permissions
The shadow file resides at /etc/shadow and is readable only by the root account. Restricting access in this way prevents unauthorized users from downloading the password hashes for offline attacks. Proper file permissions are the first line of defense protecting the integrity of stored credentials.
Typical permissions are 0400 or 0600, owned by root:root, ensuring that non-privileged processes cannot read or modify the file. Any relaxation of these permissions increases the risk of credential leakage and should be avoided on production systems.
System tools such as passwd and useradd update the shadow file in a controlled way, acquiring the required privileges through setuid helpers or privileged sockets. This design keeps direct manipulation of /etc/shadow rare and reserved for recovery or debugging scenarios.
Password Hash Algorithms
Modern shadow files support multiple hashing schemes identified by a prefix in the password_hash field. Administrators can choose algorithms such as SHA-512, SHA-256, bcrypt, or yescrypt to balance security and performance. The chosen method determines the format of the hash and the computational cost of each brute-force attempt.
$6$ indicates SHA-512, $5$ indicates SHA-256, and $y$ indicates yescrypt, while legacy DES-based hashes start without a prefix and are considered weak today. Selecting a stronger algorithm increases the work factor for attackers, significantly slowing down large-scale password cracking efforts.
When an account is locked by prefixing the hash with ! or *, authentication by password is rejected while keeping the account structure intact. This approach allows administrators to disable logins without deleting the account or losing other configuration data stored in the shadow entry.
Account Aging and Expiration Policies
Shadow entries contain numeric fields that control password aging, minimum and maximum validity periods, and warning thresholds. These settings let organizations enforce rotation schedules and reduce the risk of stale, compromised passwords remaining in use for extended periods.
The last_password_change field records when the password was last updated as the number of days since January 1, 1970. Combined with max_age, this allows automated prompts for users to change their credentials before the policy deadline is reached.
Inactive periods and expire_date provide additional control by disabling accounts after prolonged non-use or calendar-based expiration. These fields are especially useful for temporary accounts, contractors, and services that should not persist beyond a defined lifecycle.
Security Best Practices
Securing the /etc/shadow file starts with strict file permissions and minimizing the number of local privileged accounts. Centralized authentication through LDAP or Kerberos can reduce reliance on local passwords, lowering the attack surface exposed by the shadow file.
Use strong, modern hashing algorithms and enforce reasonable password policies through PAM to increase resistance against dictionary and brute-force attacks. Regular audits of shadow entries help remove obsolete accounts and identify overly permissive settings before they can be abused.
Backups that contain shadow data must be encrypted and access-controlled, treating the hashes with the same sensitivity as the live file. Any automation or scripts that interact with /etc/shadow should run with least privilege and include robust error handling to avoid accidental corruption.
Troubleshooting Common Issues
When a user is unexpectedly denied access, check both /etc/passwd and /etc/shadow for consistency in usernames and mismatched password fields. An incorrect hash, a locked account marker, or an expired date can all appear as permission problems while actually being policy-driven restrictions.
Authentication logs and tools like timedatectl help correlate login failures with clock skew or expired certificates, ensuring that password issues are not rooted in time synchronization errors. When in doubt, use passwd -S to query account status without directly parsing shadow file contents.
Key Takeaways for Administrators
- Store the shadow file with root-only permissions (0600 or 0400) to protect password hashes.
- Choose strong password hashing algorithms such as SHA-512 or yescrypt to increase cracking difficulty.
- Use account aging settings like max_age, warn_age, and inactive_period to enforce rotation and disable stale accounts.
- Prefer centralized authentication to reduce reliance on local password storage and shadow file exposure.
- Always back up the shadow file and make validated changes through supported tools whenever possible.
FAQ
Reader questions
How can I see which password hash algorithm my system is using?
Examine the second field of any line in /etc/shadow; a $6$, $5$, $y$, or missing prefix indicates the algorithm in use. Modern distributions typically default to SHA-512 ($6$) or yescrypt ($y$) depending on the configuration chosen during installation.
What does a leading exclamation mark (!) in the shadow password field mean?
It locks the account by replacing the valid hash with !, preventing password-based authentication while preserving the account structure and other settings in the shadow entry.
Can I manually edit /etc/shadow to reset a forgotten password?
Yes, you can replace the hash in the second field with a known value or use passwd --stdin where available, but prefer using passwd or usermod to ensure proper updates and avoid file corruption. Always back up the original shadow file before making manual changes.
Why do some shadow entries have an asterisk (*) instead of an exclamation mark (!)?
An asterisk (*) indicates that the account is locked and cannot be used for password authentication at all, whereas ! indicates a disabled password with the account structure intact. Both prevent login by password, but tools may treat them slightly differently during automated processes.