Password Security with Linux /etc/shadow file
Password Security on Linux
Using the /etc/shadow file
Linux systems use a password file to store accounts, commonly available as /etc/passwd. For additional safety measures, a shadow copy of this file is used which includes the passwords of your users. Or actually hashed password, for maximum security.
An example of a password entry in /etc/shadow may look like this:
user1:$6$6Y/fI1nx$zQJj6AH9asTNfhxV7NoVgxByJyE.rVKK6tKXiOGNCfWBsrTGY7wtC6Cep6co9eVNkRFrpK6koXs1NU3AZQF8v/:16092:0:99999:7:::
For proper display, let’s split this up in several fields:
- user1
- $6$6Y/fI1nx$zQJj6AH9asTNfhxV7NoVgxByJyE.rVKK6tK<truncated>
- 16092
- 0
- 99999
- 7
- <nothing>
- <nothing>
Field explanations
Time to have a look what all these strings mean:
1) Username
The first field is an easy one, it is the username of the particular account.
2) Password hashing details + hashed password
The most important string in the /etc/shadow file is definitely the secon field. It includes the password details and consists of several parts:
$6 = SHA-512
$6Y/fI1nx$ = Salt and separators. The salt is a small string of characters to mix into the hashing function. Its goal is making it more difficult to perform certain password based attacks on the hashed password. This salt consists of characters a-z, A-Z, 0-9, / and .
Long string of characters = hashed password
The long string and its length depends on the hashing method used. With $6, or SHA-512, it will 86 characters.
Lengths:
- $1 = MD5 with 22 characters
- $5 = SHA-256 with 43 characters
Notes:
When the password field has a ! or *, then the account is locked. A double ! (!!) indicates a password has never been set.
3) Last changed
This number indicates when the password was last changed. The number does indicate the day number, starting from epoch date (1 Januari 1970). Right now that is in the 16000+ range.
4) Number of days before password can be changed
This field defines how long it takes before the password can be changed. In our case zero, so it can be changed now.
5) Number of days till required password change
Another pretty self-explanatory field, stating how long is left (in days), before a password change is required. A great option to force password changes.
6) Warning threshold in days
In line with previous field it describes the number of days till a warning will be giving. In this example it is a week.
7) Expire date
Also stored in days, describing when the account was expired (from epoch date).
8) Reserved field
Usually not used by Linux distributions.
File Permissions
The /etc/shadow file should be owned by the root user, with usually shadow as group owner. This file should not be world-readable, therefore 640 or 400 would be an appropriate file permission.
Consistency checking of /etc/passwd and /etc/shadow
Linux distributions usually provide a pwck utility. This small utility will check the consistency of both files and state any specific issues. By specifying the -r it may run in read-only mode.
11:26 AM
/etc/shadow should NOT be 640. It should be 000 or 400, at the very most.
12:58 PM
I’ve added 400 in the text, although most systems don’t have that by default. I don’t suggest to use 000 as that might throw off some system administrators. Thanks for the feedback!
7:06 PM
I have a shadow file with perms 000 but still I can read that using vi editor as a root user.
Can you please explain how’s this possible?
10:54 PM
Root is always allowed to open files. To prevent files from becoming unreadable, and borking the system :)
2:17 PM
/etc/shadow file hangs forever and can not access. Also users are not able to access the system.ls -l /etc/shadow shows:
———-. 1 root root 888 Nov 30 05:17 /etc/shadow. My other systems with permission” ———-” are working fine and I do not want change the permission.Any suggestions are highly appreciated.
1:28 PM
Why did you set the permissions this strict in the first place? I suggest changing them back to the default.
10:33 PM
Do you have an idea how to have a commin passwd/shadow file over two servers, if no ldap can be used.
Server1 to server2 when user on server1 is created or a password changed.
Server 2 to server 1 when user on sever2 is created or a password changed.
Root password on server1 and server2 is different.
10:35 AM
If you want to keep things in sync, I suggest using a central service (LDAP, FreeRadius, etc). Manually copying passwd/shadow files sounds like a bad idea to me.