The /etc/shadow file on a Linux system stores critical password and account security data for local user authentication. Understanding its format, permissions, and interaction with login processes helps administrators secure access and troubleshoot identity issues.
This article walks through the structure, management, and best practices related to /etc/shadow, highlighting common fields, risks, and operational scenarios without exposing sensitive information unnecessarily.
| Field | Position | Meaning | Example Value |
|---|---|---|---|
| Username | 1 | Account name matching /etc/passwd | alice |
| Password Hash | 2 | Encrypted password or indicator (SSHA, bcrypt, SHA-512) | $6$rounds=4096$... |
| Last Password Change | 3 | Days since 1970-01-01 when password was last updated | 19876 |
| Minimum Age | 4 | Minimum days between password changes | 7 |
| Maximum Age | 5 | Maximum days before password must be changed | 90 |
| Warning Window | 6 | Days before expiry to warn user | 14 |
| Inactivity Threshold | 7 | Days after expiry until account is disabled | 30 |
| Expiry Date | 8 | Days since 1970-01-01 when account expires | 20000 |
| Reserved Flag | 9 | Reserved for future use, typically 0 | 0 |
Understanding /etc/shadow File Permissions and Ownership
Correct file permissions on /etc/shadow are essential to prevent unauthorized disclosure of password hashes. The file should be owned by root with read access limited to root and shadow group utilities, while write access is restricted to root only.
Improper permissions, such as being world-readable, immediately weaken system security and can expose password hashes for offline cracking. Administrators should routinely verify ownership and mode using stat or ls to ensure the system remains within a secure baseline.
Consistent permissions reduce the attack surface on multi-user systems and support compliance requirements for access control and audit readiness.
Password Hash Algorithms and Formats
/etc/shadow supports multiple hash families, including SHA-512, SHA-256, bcrypt, and yescrypt, each configurable through the password hashing module in libpam. Stronger algorithms increase the cost of brute-force and dictionary attacks.
The structure of the hash field includes an algorithm identifier and a salt, allowing multiple schemes to coexist on the same host without requiring a migration plan for all users at once. Selecting an appropriate rounds or cost parameter balances security and login performance.
When upgrading algorithms, existing hashes remain valid, and new passwords automatically use the strongest method supported by the system configuration.
Role of /etc/shadow in User Authentication
During login, the Pluggable Authentication Modules (PAM) stack references /etc/shadow to verify user credentials without exposing hashes to processes that do not require them. This selective access preserves confidentiality while enabling necessary authentication workflows.
System services that rely on user identities, such as sudo or cron, depend on the integrity of the shadow file to enforce policies like account expiration and password age. Misconfigurations can lead to unexpected lockouts or privilege issues.
Understanding how applications interact with shadow data helps administrators design robust authentication setups that align with security policies.
Managing Password Policies and Account Lifecycle
Fields such as minimum age, maximum age, warning window, and inactivity threshold allow centralized control over password lifecycle management. These settings reduce the risk of stale accounts and expired credentials disrupting operations.
Commands like chage and usermod provide a straightforward interface to adjust individual account policies, while configuration files such as login.defs set defaults for new users. Consistent policy enforcement across the environment simplifies compliance audits.
Periodic reviews of account expiry and inactivity settings help maintain an accurate asset inventory and prevent forgotten credentials from becoming security liabilities.
Best Practices for Securing /etc/shadow and Authentication
- Verify that /etc/shadow has permissions 0640 and is owned by root:shadow.
- Use strong hashing algorithms such as SHA-512 or bcrypt with an appropriate cost factor.
- Enforce minimum and maximum password ages to limit the impact of compromised credentials.
- Regularly audit account expiration and inactivity settings to remove or reactivate accounts as needed.
- Monitor authentication logs for repeated failures that may indicate attacks against shadow hashes.
FAQ
Reader questions
How can I check who has read access to /etc/shadow on this system?
Use the command `getfacl /etc/shadow` or `ls -l /etc/shadow` to view the current permissions and verify that only root and the shadow group have access.
What does a password hash starting with ! or * indicate in /etc/shadow?
These symbols indicate that the account is locked or otherwise disabled, preventing interactive login even if a password is set.
Can I safely backup /etc/shadow and restore it on another server?
Yes, you can copy /etc/shadow between compatible systems, but ensure that file ownership, permissions, and hash formats align to avoid authentication issues or security gaps.
Will changing the hashing algorithm automatically rehash all existing passwords in /etc/shadow?
No, existing hashes remain unchanged; new password updates will use the new algorithm based on the system configuration, while old hashes stay in place until the user changes their password.