Hubbry Logo
search
logo
Passwd avatar
Passwd
Passwd
current hub
2189789

Passwd

logo
Community Hub0 Subscribers
Read side by side
Passwd
View on Wikipedia
from Wikipedia
passwd
Original authorAT&T Bell Laboratories
DevelopersVarious open-source and commercial developers
Operating systemUnix, Unix-like, Plan 9, Inferno
PlatformCross-platform
TypeCommand

passwd is a command on Unix, Plan 9, Inferno, and most Unix-like operating systems used to change a user's password. The password entered by the user is run through a key derivation function to create a hashed version of the new password, which is saved. Only the hashed version is stored; the entered password is not saved for security reasons.

When the user logs on, the password entered by the user during the log on process is run through the same key derivation function and the resulting hashed version is compared with the saved version. If the hashes are identical, the entered password is considered to be correct, and the user is authenticated. In theory, it is possible for two different passwords to produce the same hash. However, cryptographic hash functions are designed in such a way that finding any password that produces the same hash is very difficult and practically infeasible, so if the produced hash matches the stored one, the user can be authenticated. [1]

The passwd command may be used to change passwords for local accounts, and on most systems, can also be used to change passwords managed in a distributed authentication mechanism such as NIS, Kerberos, or LDAP.

Password file

[edit]

The /etc/passwd file is a text-based database of information about users that may log into the system or other operating system user identities that own running processes.

In many operating systems, this file is just one of many possible back-ends for the more general passwd name service.

The file's name originates from one of its initial functions as it contained the data used to verify passwords of user accounts. However, on modern Unix systems the security-sensitive password information is instead often stored in a different file using shadow passwords, or other database implementations.

The /etc/passwd file typically has file system permissions that allow it to be readable by all users of the system (world-readable), although it may only be modified by the superuser or by using a few special purpose privileged commands.

The /etc/passwd file is a text file with one record per line, each describing a user account. Each record consists of seven fields separated by colons. The ordering of the records within the file is generally unimportant.

An example record may be: 

 jsmith:x:1001:1000:Joe Smith,Room 1007,(234)555-8910,(234)555-0044,email:/home/jsmith:/bin/sh

The fields, in order from left to right, are:[2]

  1. jsmith: User name: the string a user would type in when logging into the operating system: the logname. Must be unique across users listed in the file.
  2. x: Information used to validate a user's password. The format is the same as that of the analogous field in the shadow password file, with the additional convention that setting it to "x" means the actual password is found in the shadow file, a common occurrence on modern systems.[3]
  3. 1001: user identifier number, used by the operating system for internal purposes. It must be unique as it identifies users uniquely.
  4. 1000: group identifier number, which identifies the primary group of the user; all files that are created by this user may initially be accessible to this group.
  5. Joe Smith,Room 1007...: Gecos field, commentary that describes the person or account. Typically, this is a set of comma-separated values including the user's full name and contact details.[4]
  6. /home/jsmith: Path to the user's home directory.
  7. /bin/sh: Program that is started every time the user logs into the system. For an interactive user, this is usually one of the system's command line interpreters (shells).

Shadow file

[edit]

/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. [5]

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[6]), 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,[7] 64 rounds of Blowfish, 5000 rounds of SHA-256 or SHA-512.[8] 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:[9]
      • $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").[10]
    • "!", "*" – 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[11]
  • 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[quantify] 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

[edit]

Prior to password shadowing, a Unix user's hashed password was stored in the second field of their record in the /etc/passwd file (within the seven-field format as outlined above).

Password shadowing first appeared in Unix systems with the development of SunOS in the mid-1980s,[12] System V Release 3.2 in 1988 and BSD4.3 Reno in 1990. But, vendors who had performed ports from earlier UNIX releases did not always include the new password shadowing features in their releases, leaving users of those systems exposed to password file attacks.

System administrators may also arrange for the storage of passwords in distributed databases such as NIS and LDAP, rather than in files on each connected system. In the case of NIS, the shadow password mechanism is often still used on the NIS servers; in other distributed mechanisms the problem of access to the various user authentication components is handled by the security mechanisms of the underlying data repository.

In 1987, the author of the original Shadow Password Suite, Julie Haugh, experienced a computer break-in and wrote the initial release of the Shadow Suite containing the login, passwd and su commands. The original release, written for the SCO Xenix operating system, quickly got ported to other platforms. The Shadow Suite was ported to Linux in 1992 one year after the original announcement of the Linux project, and was included in many early distributions, and continues to be included in many current Linux distributions.

In the past, it was necessary to have different commands to change passwords in different authentication schemes. For example, the command to change a NIS password was yppasswd. This required users to be aware of the different methods to change passwords for different systems, and also resulted in wasteful duplication of code in the various programs that performed the same functions with different back ends. In most implementations, there is now a single passwd command, and the control of where the password is actually changed is handled transparently to the user via pluggable authentication modules (PAMs). For example, the type of hash used is dictated by the configuration of the pam_unix.so module. By default, the MD5 hash has been used, while current modules are also capable of stronger hashes such as blowfish, SHA256 and SHA512.

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Passwd

View on Grokipedia
from Grokipedia
The passwd command is a standard utility in Unix-like operating systems for updating user account passwords and managing associated password attributes.[1] It allows regular users to change their own passwords, while the superuser (root) can modify passwords for any account without needing the current password.[2] When invoked, passwd prompts for the existing password (if required) and the new one twice for verification, then updates the encrypted password in the /etc/shadow file after enforcing system-defined complexity rules, such as minimum length, avoidance of dictionary words, and restrictions on personal information.[1][3] Beyond basic password changes, passwd supports administrative functions like locking or unlocking accounts by prefixing the password field with an exclamation mark, expiring passwords to force immediate changes on next login, or deleting passwords to enable passwordless access.[1] It also displays account status, including whether a password is set, locked, or rounded to the nearest whole day for aging purposes, and integrates with system-defined password aging policies, such as minimum and maximum days between changes.[2] Historically rooted in early Unix systems, passwd originally used DES-based encryption but now supports stronger methods like SHA-512, depending on the system's ENCRYPT_METHOD setting, to enhance security against brute-force attacks.[1] This command is essential for user authentication management and is available across major distributions, including Linux, Solaris, and z/OS variants.[4][3]

User Account Files

/etc/passwd File

The /etc/passwd file serves as the primary plain-text database for user account information in Unix-like operating systems, located at /etc/passwd and containing one line per user account.[5] This file is world-readable to allow utilities and applications to access basic user details without elevated privileges.[6] Each entry consists of seven colon-separated fields that define essential attributes for login and resource allocation. The first field is the username, a unique string limited to a maximum of 32 characters in modern systems, though historically restricted to eight.[7] The second field is the password field. Originally, this field stored the encrypted user password directly. In modern systems using the shadow password suite, it contains an 'x' as a placeholder, indicating that the actual password hash is stored in the more secure /etc/shadow file, which is readable only by root.[5] If this field is empty (two consecutive colons with no character in between, e.g., username::uid:gid:...), the system treats the account as having no password, allowing login without prompting for one. This legacy behavior bypasses /etc/shadow and is highly insecure, as it permits unauthenticated access if the file is tampered with or improperly modified. On contemporary Linux distributions where shadow passwords are standard, this method is not recommended and may be restricted or inconsistent due to PAM configurations or enforcement of shadow usage. The secure and proper way to enable passwordless login is via the passwd -d username command (executed as root or with sudo), which clears the password entry in /etc/shadow while retaining the 'x' in /etc/passwd.[5][8][9] The third field is the user ID (UID), a numeric value starting at 0 for the root superuser and generally ranging from 1000 upward for regular users.[6] The fourth field specifies the primary group ID (GID), another numeric identifier linking the user to their default group. The fifth field, known as the GECOS field, provides optional comma-separated comments such as the user's full name, office location, or contact details.[5] The sixth field denotes the home directory path, where the user's personal files and environment are typically stored.[7] Finally, the seventh field indicates the login shell, the command interpreter executed upon login, defaulting to /bin/sh if left empty.[6] A representative entry might appear as follows: 
user:x:1000:1000:User Name:/home/user:/bin/bash
In this example, "user" is the username, "x" marks the password placeholder, 1000 is both the UID and GID, "User Name" is the GECOS comment, "/home/user" is the home directory, and "/bin/bash" is the shell.[5] During system authentication, the /etc/passwd file is consulted to retrieve the UID and GID for mapping user identities to processes and resources after successful login verification.[7] With the adoption of shadow password suites, password validation occurs separately, leaving this file focused on non-sensitive metadata.[6] The file is owned by the root user and maintains permissions of 644 (read and write for owner, read-only for group and others) to balance accessibility and protection.

/etc/shadow File

The /etc/shadow file is a text-based configuration file located at /etc/shadow in Unix-like operating systems, designed to store sensitive user password information and password aging metadata that cannot be safely kept in world-readable files.[10] It enhances security by separating hashed passwords from the publicly accessible /etc/passwd file, reducing the risk of unauthorized access to credential data.[11] This file is owned by the root user and typically belongs to the shadow group, with permissions set to 640 (readable and writable by root, readable by the shadow group) or 600 (readable and writable only by root), ensuring that only privileged processes can access its contents.[11][12] Each line in the /etc/shadow file corresponds to a user account and consists of nine colon-separated fields, providing comprehensive details on password management.[10] The fields are as follows:
FieldDescriptionExample Value
1. UsernameThe login name of the user, matching an entry in /etc/passwd.user
2. Encrypted passwordA hashed password using algorithms such as DES (traditional crypt), MD5 ($1$), SHA-256 ($5$), or SHA-512 ($6$); prefixed with the algorithm identifier, salt, and hash; disabled accounts use !, !!, or *.$6$salt$hashvalue
3. Last password changeNumber of days since January 1, 1970 (Unix epoch), when the password was last changed. A value of 0 means the password must be changed at the next login.18400
4. Minimum password ageMinimum number of days required between password changes; 0 allows immediate changes.0
5. Maximum password ageMaximum number of days a password remains valid before expiration; 99999 often indicates no expiration.99999
6. Password warning periodNumber of days to warn the user before password expiration.7
7. Password inactivity periodNumber of days after expiration before the account is locked.(empty)
8. Account expiration dateNumber of days since the epoch when the account expires.(empty)
9. ReservedA field for future use, typically left empty.(empty)
These fields enable fine-grained control over password policies, such as enforcing regular changes and automatic account disabling to mitigate brute-force attacks and stale credentials.[13][14] A representative entry might appear as: 
user:$6$abc123$longhashhereabcde...:18400:0:99999:7:::
Here, the username is user; the encrypted password uses SHA-512 ($6$) with salt abc123 and the subsequent hash; the password was last changed 18,400 days after the epoch (around 2020); no minimum age is enforced; the password expires after 99,999 days; warnings begin 7 days prior; and the remaining fields are empty, indicating no inactivity lock or account expiration.[13][11] The /etc/shadow file integrates with /etc/passwd by having the latter's password field set to x, signaling authentication modules to consult /etc/shadow for verification.[10] Programs like login, su, and sudo, often via the Pluggable Authentication Modules (PAM) framework—specifically the pam_unix module—read this file to authenticate users against the stored hashes without exposing them system-wide.[15][16] The shadow password system was introduced in the mid-1980s, first in Sun Microsystems' SunOS, to address vulnerabilities in storing hashes within the readable /etc/passwd file, and was later standardized in System V Release 3.2 (1988) and adopted in BSD variants by 1990.[17][18] This separation became a cornerstone of Unix security, influencing modern Linux distributions and other Unix-like systems.[19]

The passwd Command

Syntax and Basic Usage

The passwd command is a setuid root binary located at /usr/bin/passwd, enabling non-root users to change their own passwords while allowing the root user to manage passwords for any user account.[1][20] This design ensures that password updates, which require elevated privileges to modify system files, can be performed securely without granting full root access to ordinary users.[20] The command integrates with Pluggable Authentication Modules (PAM) to handle authentication and enforce password policies during the change process.[1] The basic syntax of the command is: 
passwd [options] [username]
Omitting the username argument targets the current user's password, making it suitable for interactive use by regular users.[1] For root, specifying a username allows changing another account's password without needing the current password of that account.[1] The command assumes the target is a local account defined in the system's user database.[1] In basic interactive usage, invoking passwd without options prompts the user first for their current password (one attempt, skipped if run as root).[1] It then requests the new password twice for confirmation; if the entries match and satisfy PAM-enforced constraints—such as minimum length, complexity requirements, and password aging rules—the command proceeds.[1] Upon success, it computes and stores the hashed new password in the /etc/shadow file.[1] For scripted or non-interactive scenarios, the command supports reading the new password from standard input, as in echo "newpassword" | passwd --stdin username, facilitating automation while still requiring appropriate privileges.[1] The passwd command returns specific exit codes to indicate outcomes: 0 for success, 1 for permission denied, 3 for unexpected failure with no changes made, and 4 for unexpected failure due to the password file being missing.[1] These codes allow scripts and administrators to detect and handle errors programmatically.[1]

Options and Advanced Features

The passwd command supports several command-line options that enable administrators to manage user accounts beyond basic password changes, such as locking, unlocking, or querying status.[1] The -l or --lock option locks a user account by prefixing the password hash in the /etc/shadow file with an exclamation mark (!), preventing login attempts until unlocked.[1] Conversely, the -u or --unlock option removes this prefix to restore access.[1] The -d or --delete option deletes the user's password, making it empty in /etc/shadow, which sets the account to be passwordless (status NP for no password) and allows login without a password. This is the recommended method for configuring passwordless access, as it preserves the shadow password mechanism by retaining the 'x' in the /etc/passwd password field. Manually removing the 'x' from the password field in /etc/passwd and leaving it blank (e.g., username::uid:gid:...) is a legacy method that bypasses /etc/shadow entirely, permitting passwordless login but is highly insecure, not recommended, and may behave inconsistently or be restricted on modern systems that enforce shadow passwords and PAM configurations (such as pam_unix with nullok or nonull options). Passwordless accounts should be used with caution, typically only for temporary access or in combination with other security measures.[1][21][10] To force a password expiration, the -e or --expire option sets the last password change date to zero in the shadow file, requiring an immediate change on next login.[1] The -S or --status option provides a report on the account's password status, outputting details such as the username, password status (e.g., P for password set, L for locked, NP for no password), last change date, minimum days between changes, maximum days before expiration, warning days, and inactivity period; for example, user P 05/15/2023 0 99999 7 -1 indicates a password set with no expiration constraints.[1] When used with -a or --all, it reports status for all users.[1] Administrators running as root can specify a target username (e.g., passwd otheruser) to modify any account's password without the current user's involvement.[1] For non-interactive scripting, the --stdin option reads the new password directly from standard input as a single line, facilitating automation while bypassing prompts.[1] Additional administrative options allow direct manipulation of shadow file fields for password aging: -n or --mindays sets the minimum days required between password changes, -x or --maxdays establishes the maximum validity period, and -w or --warndays configures the advance warning days before expiration.[1] These options update the corresponding fields in /etc/shadow without altering the password itself.[1] The passwd command integrates with Pluggable Authentication Modules (PAM) for advanced features like password quality enforcement, where modules such as pam_pwquality or pam_cracklib perform checks for strength, dictionary words, and complexity rules during password updates.[1][22] For instance, pam_cracklib rejects passwords resembling dictionary entries or common patterns to mitigate brute-force risks.[23] Input handling supports both cleartext passwords (prompted or via --stdin) and pre-encrypted hashes when provided by administrators, with PAM managing the encryption using system-configured algorithms like SHA-512.[1] Platform implementations vary slightly; in GNU coreutils (common on Linux distributions), options like -R or --root enable chroot directory specification for restricted environments, while FreeBSD's passwd emphasizes NIS/Kerberos support with options like -l to update only local passwords and -y to force NIS mode.[1][24] These differences stem from project-specific enhancements, with BSD variants emphasizing NIS/Kerberos support.[24] Common errors include "Authentication token manipulation error," which typically indicates failures in updating the shadow file due to permission issues (e.g., non-root access without sudo), full disk space, or filesystem read-only states; resolution often involves verifying write access to /etc/shadow and related directories.[25]

Historical Development

Origins in Early Unix

The passwd system originated during the development of Unix at Bell Labs, part of AT&T, beginning in 1969 with initial work by Ken Thompson on a PDP-7 computer.[26] Unix evolved as a simplified alternative to the more complex Multics system, on which Thompson and Dennis Ritchie had previously collaborated, incorporating lessons in multi-user time-sharing and file-based resource management.[26] By 1971, the first internal manual described a basic multi-user environment where user authentication relied on a dedicated password file to support login processes.[27] The /etc/passwd file emerged as the core mechanism for user account management in early Unix, introduced around Version 3 in 1973 as an ASCII text file storing essential user details.[28] Its original design featured colon-separated fields for each user, including the login name, encrypted password, user ID (UID), comment field (such as GCOS job information), home directory, and shell. The group ID (GID) field was added later in Version 7.[28] Passwords were encrypted using an early one-way function based on a simulation of the M-209 cipher machine, where the password served as the key to encipher a constant value, producing an 8-character output stored in the file.[29] This file was made world-readable to allow non-privileged programs, like the login(1) utility, to access user metadata such as UIDs and home directories for authentication and session setup, reflecting the simple security model of small-scale research systems at the time.[26] Thompson and Ritchie, as primary architects, shaped this integrated approach to prioritize ease of implementation over stringent access controls.[26] A key milestone came with the Seventh Edition of Unix in 1979, which introduced the seven-field format of /etc/passwd, adding the group ID (GID) field and integrating it more firmly with the login(1) program for verifying credentials during user sessions. However, the design exhibited initial limitations suited to its era: passwords lacked aging mechanisms or expiration policies, and the single, readable file combined authentication data with account information, creating risks as user bases grew beyond a handful of developers.[29] These constraints stemmed from the system's origins in a trusted internal environment, where comprehensive separation of concerns was not yet prioritized.[26]

Evolution to Shadow Passwords

The shadow password system emerged in the mid-1980s to address security limitations in the original /etc/passwd file, where encrypted passwords were world-readable, enabling offline cracking by any user. It was first implemented in SunOS during this period and introduced in 1987 by Julianne Frances Haugh for SCO Xenix after experiencing a system break-in; this suite separated sensitive password data into the /etc/shadow file, restricted to root access only, while retaining user account details in /etc/passwd for non-privileged processes like getpwent(). The approach was later adopted in System V Release 3.2 in 1988 and BSD 4.3 Reno in 1990, becoming a standard feature across Unix variants by the early 1990s. These functions for accessing the shadow database were formalized in the POSIX.1-2008 standard to ensure portability.[18][19] Key drivers for the shift included heightened awareness of vulnerabilities highlighted by password-cracking tools, notably Crack version 4.1 released in 1992 by Alec Muffett, which exploited the readability of DES-encrypted passwords in /etc/passwd to perform dictionary and brute-force attacks efficiently on commodity hardware. This underscored the need for password aging mechanisms—tracking last change dates, minimum age, and expiration—to encourage frequent updates and limit reuse, features natively supported in /etc/shadow. Concurrently, the 1990s saw a transition from the vulnerable DES-based crypt(3) algorithm to MD5 hashing in many Unix systems, providing longer hashes (128 bits) and slower computation to deter exhaustive searches.[30] Standardization efforts aligned shadow passwords with cryptographic requirements, including FIPS 140-2 compliance for validated hashing modules used in federal systems, ensuring robust protection against key recovery attacks. In the 1990s, integration with networked authentication protocols like NIS (Network Information Service) and LDAP (Lightweight Directory Access Protocol) extended shadow functionality to distributed environments, allowing synchronized password management across multiple hosts without exposing hashes over the network. Modern adaptations have focused on enhancing policy enforcement and resilience; the libpwquality library, developed in the early 2010s by Red Hat, provides APIs for checking password strength against configurable rules like entropy scores and cracklib dictionaries during passwd operations. In the 2020s, distributions began adopting newer hashing: Fedora switched to yescrypt (a memory-hard function) as default in 2021, and Red Hat Enterprise Linux added bcrypt support in 2024 (version 8.10), both providing stronger protection against parallel attacks.[31][32] Argon2 support remains limited outside specialized modules. Along this timeline, the 2000s marked the widespread maturation of Pluggable Authentication Modules (PAM), first developed by Sun Microsystems in 1994, integrated into Solaris 2.6 in 1997, and adopted in open-source Linux distributions starting in 1996, which replaced direct /etc/shadow access with modular interfaces for authentication, enabling extensions like multi-factor support without altering core files.

Security Considerations

Vulnerabilities in Traditional Systems

In early Unix systems, the /etc/passwd file stored encrypted passwords alongside user account details in a world-readable format, enabling any local user or attacker with file access to copy the password hashes for offline cracking attempts. This design choice, intended to support utilities like finger that required access to user information, exposed the system to significant risks, as attackers could extract and analyze the hashes without needing ongoing system access.[33] The traditional encryption relied on the DES-based crypt() function, which used a 12-bit salt to vary the hash output and deter precomputed attacks; however, this short salt length proved insufficient against rainbow table attacks, as it limited the number of unique hash variations to just 4,096 per password, allowing attackers to generate feasible tables for common passwords. The crypt() algorithm itself was vulnerable due to its reliance on a modified DES encryption of a fixed 64-bit block repeated 25 times, which was computationally inexpensive to reverse with growing hardware capabilities by the early 1990s.[34][35][36] Tools like John the Ripper, first released in 1996, specifically targeted these DES-based hashes from /etc/passwd files, enabling efficient brute-force and dictionary attacks that could crack weak or common passwords in hours or days on contemporary hardware. Variants of John the Ripper further optimized for DES cracking, demonstrating how the exposed, unsalted-equivalent hashes facilitated rapid compromise of user accounts.[37][38] Although traditional systems included basic password aging mechanisms in the /etc/passwd file, their world-readable nature made them insecure, often leading to stale passwords that users rarely updated, increasing the likelihood of compromise from dictionary attacks or reused credentials. This gap contributed to historical incidents, such as the 1988 Morris Worm, which exploited weak default passwords like "guest" or simple variants of usernames to propagate across Unix networks, infecting an estimated 10% of the internet at the time.[39][40] The passwd command's setuid root privilege allowed it to modify protected files like /etc/passwd, but this elevated execution model created risks for local privilege escalation if misconfigured, such as through improper permissions on supporting libraries or environment variables that could be manipulated by unprivileged users. In pre-2000 BSD variants, buffer overflows in the passwd utility—particularly when handling long GECOS fields or shell specifications—enabled local attackers to overwrite stack memory and execute arbitrary code as root, as seen in vulnerabilities affecting BSD 4.3 and earlier releases. These flaws in crypt() and related components, along with exposed files, have been linked to real-world reconnaissance in breaches where /etc/passwd leaks aided targeted phishing or brute-force attempts against enumerated usernames. To address these issues, the shadow password system was introduced to segregate sensitive data.[41][42][43]

Modern Best Practices

In modern Linux systems, password hashing for the /etc/shadow file should employ strong, adaptive algorithms to resist brute-force attacks, such as Argon2id, PBKDF2 with at least 600,000 iterations, bcrypt, or scrypt, as recommended by the OWASP Password Storage Cheat Sheet.[44] Algorithms like MD5 and DES-based crypt must be avoided due to their vulnerability to modern hardware.[44] Configuration is typically set in /etc/login.defs using the ENCRYPT_METHOD directive, for example, ENCRYPT_METHOD SHA512 for systems supporting SHA-512, which provides 256-bit security equivalent when combined with sufficient salt and rounds.[45] Newer distributions may prefer yescrypt for its memory-hard properties, enhancing protection against GPU-accelerated cracking.[44] Access controls for password files are essential to prevent unauthorized reads. The /etc/shadow file should have permissions set to 600 (readable and writable only by root) or 640 (readable by the shadow group) to restrict access while allowing necessary operations, minimizing exposure in compromised environments.[46] Integration with Pluggable Authentication Modules (PAM) via pam_pwquality enforces robust policies, such as a minimum password length of 12 characters, requirements for diverse character classes (e.g., uppercase, lowercase, digits, symbols), and prohibition of password reuse within the last 5 changes.[47] For multi-factor authentication, PAM can stack modules like pam_google_authenticator alongside local passwords, ensuring layered security without relying solely on /etc/shadow.[33] When using the passwd command, interactive mode is preferred for user-driven changes to avoid exposing passwords in process lists or logs; the --stdin option should only be used in secure, automated scripts with input from protected sources like /dev/urandom or encrypted vaults, and never in multi-user or networked contexts.[1] The passwd command also provides the -d (--delete) option, available only to the superuser, to delete a user's password from /etc/shadow, resulting in a passwordless account that permits login without authentication. This is the recommended and secure method for configuring passwordless access when required (e.g., for certain system accounts), as it properly updates /etc/shadow while retaining the 'x' in /etc/passwd. Manually editing /etc/passwd to remove the 'x' and leave the password field blank invokes legacy behavior that bypasses /etc/shadow entirely but is highly insecure, strongly discouraged, and may behave inconsistently or be restricted on modern systems where shadow passwords are enforced and PAM configurations may block null passwords. Passwordless accounts pose severe security risks and should be used only when absolutely necessary, with extreme caution, and never for general user accounts.[1][21] Regular integrity audits are recommended using tools like pwck, which verifies consistency between /etc/passwd and /etc/shadow, checking for valid fields, duplicate entries, and proper formatting to detect tampering.[48] For networked environments, local /etc/passwd and /etc/shadow files should not be directly exposed over protocols like NFS; instead, implement centralized authentication using SSSD (System Security Services Daemon) integrated with FreeIPA or LDAP backends to manage credentials remotely while caching for offline access.[49] This approach reduces the attack surface by avoiding replication of sensitive files across hosts. These practices align with NIST SP 800-63B guidelines (revision 4, 2024), which emphasize verifier-side storage of salted hashes resistant to offline attacks, minimum lengths of 8 characters for user-chosen passwords (with encouragement for longer passphrases up to 64 characters), avoidance of composition rules, and blacklisting of compromised passwords without mandatory periodic changes.[50] Regarding post-quantum threats, memory-hard functions like Argon2 or yescrypt in PAM configurations provide forward resistance, as they complicate Grover's algorithm exploitation on quantum hardware.[44]

References

  1. passwd(1) - Linux manual page - man7.org
  2. Managing Linux users with the passwd command - Red Hat
  3. passwd - man pages section 1: User Commands - Oracle Help Center
  4. Using the passwd command - IBM
  5. passwd(5) - Linux manual page - man7.org
  6. Understanding the /etc/passwd File - Linuxize
  7. Understanding the /etc/passwd File - phoenixNAP
  8. shadow(5) - Linux manual page - man7.org
  9. Understanding the /etc/shadow File - Linuxize
  10. 6.3.2.2. /etc/shadow | Red Hat Enterprise Linux | 4
  11. Understanding /etc/shadow file format on Linux - nixCraft
  12. Description - man pages section 4: File Formats
  13. 2 Authentication with PAM - SUSE Documentation
  14. Anatomy of a Linux Pluggable Authentication Modules (PAM ...
  15. UNIX: The /etc/shadow File in Depth - MangoLassi
  16. [PDF] Introduction to the Shadow Password Suite - USENIX
  17. When did Unix stop storing passwords in clear text?
  18. How to make setuid / suid shell scripts work the way setuid binaries ...
  19. pam_pwquality(8) - Linux man page - Die.net
  20. Features/PasswordQualityChecking - Fedora Project Wiki
  21. https://man.freebsd.org/cgi/man.cgi?passwd(1
  22. Users getting message "passwd: Authentication token manipulation ...
  23. [PDF] The UNIX Time- Sharing System
  24. Unix Manual, first edition - Nokia
  25. [PDF] UNIX Programmer's Manual: Third Edition - Free
  26. [PDF] Password Security: A Case History
  27. crypt(3) - Linux manual page - man7.org
  28. Chapter 4. Hardening Your System with Tools and Services | 7
  29. passlib.hash.des_crypt - DES Crypt - Read the Docs
  30. Of History & Hashes: A Brief History of Password… - TrustedSec
  31. [PDF] UNIX Password Encryption Considered Insecure - phwl
  32. john-users - Re: When was John created? - Openwall
  33. John the Ripper documentation - Openwall
  34. The secrets of password aging on Unix systems - Network World
  35. The Morris Worm: how it Affected Computer Security and ... - People
  36. How does the 'passwd' command gain root user permissions?
  37. bsd bsd 4.3 vulnerabilities and exploits - Vulmon
  38. What can hackers do with ability to read /etc/passwd?
  39. Password Storage - OWASP Cheat Sheet Series
  40. login.defs(5) - Linux manual page - man7.org
  41. etc/shadow permissions security best practice (000 vs. 600 vs. 640)
  42. Creating a Password Policy in Linux - Putorius
  43. https://man7.org/linux/man-pages/man8/pwck.8.html
  44. Chapter 3. Understanding SSSD and its benefits
  45. NIST Special Publication 800-63B
  46. Linux man page: passwd(1)
  47. Linux man page: shadow(5)
  48. passwd(5) - Linux manual page
  49. shadow(5) - Linux manual page
  50. passwd(5) - Linux manual page
User Avatar
No comments yet.