/etc/shadow is used to increase the security level of passwords by restricting all but highly privileged users' access to hashed password data. Typically, that data is kept in files owned by and accessible only by the
super user. Systems administrators can reduce the likelihood of brute-force attacks by making the list of hashed passwords unreadable by unprivileged users. The obvious way to do this is to make the passwd database itself readable only by the root user. However, this would restrict access to other data in the file such as username-to-userid mappings, which would break many existing utilities and provisions. One solution is a "shadow" password file to hold the password hashes separate from the other data in the world-readable
passwd file. For local files, this is usually /etc/shadow on
Linux and Unix systems, or /etc/master.passwd on
BSD systems; each is readable only by
root. (Root access to the data is considered acceptable since on systems with the traditional "all-powerful root" security model, the root user would be able to obtain the information in other ways in any case). Virtually all recent
Unix-like operating systems use shadowed passwords. The shadow password file does not entirely solve the problem of attacker access to hashed passwords, as some network authentication schemes operate by transmitting the hashed password over the network (sometimes in
cleartext, e.g.,
Telnet), making it vulnerable to interception. Copies of system data, such as system backups written to tape or optical media, can also become a means for illicitly obtaining hashed passwords. In addition, the functions used by legitimate password-checking programs need to be written in such a way that malicious programs cannot make rapid authentication checks. Regardless of whether password shadowing is in effect on a given system, the passwd file is readable by all users so that various system utilities (e.g.,
grep) can work (e.g., to ensure that user names existing on the system can be found inside the file), while only the root user can write to it. Without password shadowing, this means that an attacker with unprivileged access to the system can obtain the hashed form of every user's password. Those values can be used to mount a
brute force attack offline, testing possible passwords against the hashed passwords relatively quickly without alerting system security arrangements designed to detect an abnormal number of failed
login attempts. Especially when the hash is not salted it is also possible to look up these hashed passwords in
rainbow tables, databases specially made for giving back a password for a unique hash. With a shadowed password scheme in use, the /etc/passwd file typically shows a character such as '*', or 'x' in the password field for each user instead of the hashed password, and /etc/shadow usually contains the following user information: • User login name •
salt and hashed password OR a status exception value e.g.: • $id$salt$hashed, the printable form of a password hash as produced by
crypt (C), where $id is the algorithm used. Other Unix-like systems may have different values, like NetBSD.
Key stretching is used to increase
password cracking difficulty, using by default 1000 rounds of modified MD5, 64 rounds of Blowfish, 5000 rounds of SHA-256 or SHA-512. The number of rounds may be varied for Blowfish, or for SHA-256 and SHA-512 by using $A$rounds=X$, where "A" and "X" are the algorithm IDs and the number of rounds. Common id values include: • $1$ – MD5 • $2$, $2a$, $2b$ –
bcrypt • $5$ – SHA-256 • $6$ – SHA-512 • $y$ –
yescrypt •
Empty string – No password, the account has no password (reported by passwd on Solaris with "NP"). • "!", "*" – the account is password locked, user will be unable to log in via password authentication but other methods (e.g. ssh key, logging in as root) may be still allowed. • "*LK*" – the account itself is locked, user will be unable to log in. • "*NP*", "!!" – the password has never been set • Days since
epoch of last password change • Days until change allowed • Days before change required • Days warning for expiration • Days after no logins before account is locked • Days since epoch when account expires • Reserved and unused The format of the shadow file is simple, and basically identical to that of the password file, to wit, one line per user, ordered fields on each line, and fields separated by colons. Many systems require the order of user lines in the shadow file be identical to the order of the corresponding users in the password file. == History ==