Have you wondered how Linux efficiently manages a multi-user environment? In this article we explain how Linux stores and manages user passwords and logins.
Exploring /etc/passwd file
When a user enters a username and password, Linux checks the password entered against an an entry in several files in the “/etc” directory.
The “/etc/passwd” is one of the most important files that stores user details.
The last entry in this file corresponds to “carbon” users. There are multiple fields of information separated by colons (:).
carbon: name of the user for whom this entry corresponds to.x: indicates that a password exists for the user. However, the password is stored in the “/etc/shadow” file. If instead ofxit shows a!symbol, this indicates that a password does not exist.1000: User ID of this user.1000: Group ID of the group this user belongs to.carbon, , ,: indicating multiple fields of information inclusive of full name and telephone numbers. Here, no telephone numbers have been provided./home/carbon: location of home directory assigned to this user./bin/bash: default shell assigned to this user.
Let us create another user for whom some telephone numbers have been stored. The user “pluto” is added to the system using the adduser command.
Looking at the “etc/passwd” file again, we can view the complete information for the user “pluto.” The field which has a comma-separated list of full name and numbers is called as “GECOS field.”
Whenever a user is created, values of the home directory and default shell that need to be assigned are specified in the “/etc/adduser.conf” file.
User IDs for created users begin from 1000 and run up to 59999.
The user “carbon” was able to view the entries of the “/etc/passwd” file simply by using the cat command. Let us take a look at its permissions.
Only the “root” user can write to the file. Other users can only read the file. Since this file is readable by everyone, it is not ideal to store passwords here. Instead it is stored in another file called “/etc/shadow.”
Exploring the /etc/shadow File
Now let us try to view the stored password for users “carbon” and “pluto” in the”/etc/shadow” file.
Taking a look at the permissions for the “/etc/shadow” file, we can see that only the “root” user can read and write to the file. Also only members of the group “shadow” can read the file. In reality, the “shadow” group is empty but is syntactically required for this file.
Logging in as “root,” we can view the last ten lines of “/etc/shadow.” For every entry in “/etc/passwd,” there is a corresponding entry in this file. The format will be like this:
pluto:$6$JvWfZ9u....:18283:0:99999:7:::
In this file, too, every entry has multiple fields separated by colons (:). Let us decipher the entry for the “pluto” user.
pluto: name of the user for whom this entry corresponds to.$6$JvWfZ9u.$yGFIqOJ....: The hashed user password stored along with information about the hashing algorithm used. Additionally, a salt value is used along with the plaintext password to generate the password hash.
{ plaintext password, salt} -> hashed password
Let us process the content in this field. The $ symbol is used as a delimiter to separate three fields.
$6 $JvWfZ9u. $yGFIqOJ....
$6: the hashing algorithm used. Here is the list of potential hashing algorithms.- $1 : MD5
- $2a : Blowfish
- $2y : Eksblowfish
- $5 : SHA-256
- $6 : SHA-512
$JvWfZ9u.: salt value.$yGFIqOJ....: hashed password.
The resulting hash value is stored as the encrypted password for a user. The salt value is unique for every user. Even if two users have the same plaintext password, using a unique salt would generate a unique hash value.
Following with the remaining fields in this entry,
18283: Indicates the number of days since January 1, 1970, that the password was last changed0: this field is used to indicate the number of days after which the password can be changed. A value of 0 means the password can be changed at any time.99999: this field indicates the number of days after which the password must be changed. A value of 99999 indicates a user can retain the password as long as desired.7: if the password is set to expire, this fields indicates the number of days to warn the user about password expiry.: : :Three more fields are a part of this entry, although they are empty here. The first one indicates the number of days to wait after password expiry, following which the account will be disabled. The second one indicates the number of days since January 1, 1970, that an account has been disabled. The third field is reserved for future use. The empty fields indicate that the existing password for this user has not expired and is not set to expire soon.
The last seven fields pertaining to password validity are collectively said to hold information about “Password Aging Policy.”
The default values corresponding to “Password Aging Policy” are specified in the “/etc/login.defs” file. These values can be altered for a user using the change command.
What about group information?
User information and passwords are stored in the “/etc/passwd” and “/etc/shadow” files. Likewise, group information is stored in the “/etc/group” file.
Highlighted above are groups belonging to users “carbon” and “pluto.” When a user is created in Linux, that user is immediately assigned to a group with the same name as the user name.
Members of a group can share a group password, too, for group-related activities. The value of x indicates that the password information for that group would be in the “/etc/gshadow” file.
However, access to “/etc/gshadow” is restricted to the “root” user.
The “root” user can view the entries of “/etc/gshadow,” which is similar to “/etc/shadow.” Looking at the entry for the “carbon” group, we can see that the second field has a value of !, which indicates that a password does not exist for this group.
Putting it all together
When a user wishes to log in, the hash of the typed password is found using that user’s salt value in “/etc/shadow.” Then it is compared with the stored hash. If the values match, the user is granted access.
Related:
The screen shot of the /etc/shadow file is barely readable because of the small font. All the other screen shots are larger and more readable.
Thank you for your feedback!
That screenshot was necessary to capture the full length of information. On some systems, it seems legible enough. Maybe you can use the “zoom” feature of your web browser to look into that section?
The ‘$’ is just a field separator – it is not part of either the algorithm ID nor the salt.