Our world would have been more peaceful if there was no fear of theft.

We would have left our doors open and enjoyed better privacy and security. In today’s world, that is impossible and hence the need for doors and locks. A similar case applies to the digital world, where we must assure complete data security. The simplest yet most important way to protect data even today remains with passwords and access management systems.

“A password is a word or string of characters used for user authentication to prove identity or access approval to gain access to a resource (Eg: an access code is a type of password, which should be kept secret from those not allowed access.)”

The user utilizes the password every time he/she wanted to access a particular resource or asset. Passwords must be safeguarded to ensure total secrecy. Storing passwords in plain text is not advisable. The password must stay away from the reach of any other user.

The solution lies in encoding/encryption/hashing the password and storing it in a secured location. Even then, there is a possibility of decrypting the password back from its encrypted form. Through the use of advanced tools available today, most hackers can reverse engineer the encrypted passwords quickly.

During the earlier days of Unix, passwords got stored in the /etc/passwd file.

An /etc/passwd file has the following format:

username:passwd:UID:GID:full_name:directory:shell

Let’s take a closer look at the permissions of /etc/passwd file and try to modify them:

root@etcHacked:~# ll /etc/passwd
-rw-r--r-- 1 root root 1956 Dec 14 01:17 /etc/passwd
root@etcHacked:~# chmod 600 /etc/passwd
root@etcHacked:~# ll /etc/passwd
-rw------- 1 root root 1956 Dec 14 01:17 /etc/passwd
root@etcHacked:~# su - etc-hacked
I have no name!@etcHacked:~$

If we want to change the user now, we will not get the username, home directory, or custom shell. To avoid this, store them in /etc/passwd file and keep this file readable for everyone.

You can also store the password using the Shadow-Utils package, which is an alternative way of keeping the password.

Shadow-Utils Package

Shadow-Utils is a package for improving system security by moving the encrypted passwords (usually found in /etc/passwd) to /etc/shadow, which is readable only by root. Most of the Linux machines have pre-installed Shadow-Utils.

Here is the permission of /etc/shadow file:

root@etcHacked:~# ll /etc/shadow
-r-------- 1 root shadow 1040 Dec 14 01:17 /etc/shadow
root@etcHacked:~# cat /etc/shadow
etc-hacked:$1$4hx$XLjr/pkLpIjbwhrxmuQyb.:16418:0:99999:7:::

Only root has the permission of ‘r’ (read) for the /etc/shadow file. The file has several fields.
Each field is separated by a colon (:). There are several fields, these include:

  1. User name: Must match up with a user name in /etc/passwd; it is the key.
  2. Password: Field is a hash of the password (not the actual password itself) combined with an id (specifying which form of encryption was used).
  3. Last changed date: The day that the password was last set (in days since January 1, 1970), also called UNIX Time.
  4. Minimum days: Minimum number of days that a password must remain active before it can be changed. Passwords cannot be changed until the specified number of days has elapsed.
  5. Maximum days: Maximum number of days for a password to be valid. Once the maximum number of days has elapsed, the user is forced to change their password.
  6. Warn days: Before a password expires, warn the user this many days ahead of time.
  7. Inactive days: Once a password has expired, it will be disabled after this many days.
  8. Expire date: On this date (in days since January 1, 1970), the account is disabled, and the login is disabled.


Instead of computing the days since 1970, use the chage command:
root@etcHacked:~# chage -l root
Last password change : December 14, 2014
Password expires : never
Password inactive : never
Account expires : never
Minimum number of days between password change : 0
Maximum number of days between password change : 99999
Number of days of warning before password expires : 7
root@etcHacked:~#

How the Password is Stored and Verified upon Login

Look at the second field – the hashed password - $1$4hx$XLjr/pkLpIjbwhrxmuQyb

The password hash comes in three parts, separated by dollar signs ($):

  • Id.
    This identifies the encryption hash method used.
    A value of:
    • 1 denotes MD5
    • 2 or 2a is Blowfish
    • 3 is NT hash
    • 5 is SHA-256
    • 6 is SHA-512
  • Salt.
    This is used by the encryption algorithms and could be up to 16 characters. It adds an extra level of strength to hash by combining itself with the original password.
  • Hash.
    The actual “password” (or hash) is last. MD5 uses 22 characters, SHA-256 uses 43, and SHA-512 uses 86.
    In this case, the Hashing Algorithm is MD5($1$), Salt Value is 4hx and PASSWORD+SALT is XLjr/pkLpIjbwhrxmuQyb. You can crosscheck the password by hashing it manually with the salt by running following command. Here -1 is the hashing algorithm is MD5.

    root@etcHacked:~# openssl passwd -1 -salt 4hx root
    $1$4hx$XLjr/pkLpIjbwhrxmuQyb.
    root@etcHacked:~#

    If the password entry is missing (which means no password) or it is a locked account. Now, if the password is entered on the login page of Linux, the password is hashed with Salt and matched with the stored value of /etc/shadow, if it is a match, the user is logged into the machine.

Benefits of using Salt

Salt makes it tough to crack a list of passwords. However, it not only ensures cracking a password using dictionary attacks harder, it increases the cost of such an operation higher. Even if the attacker has access to both the hashed password and the Salt, the attacker might use the known Salt when attempting to crack the password when running the dictionary attack.

To understand the difference between cracking a single password and a set of them, consider a single password file that contains many usernames and passwords. Without Salt, an attacker could compute hash(attempt[0]), and then check whether that hash appears anywhere in the file.

The likelihood of a match, i.e. cracking one of the passwords with that attempt, increases with the number of passwords in the file. If Salts are present, the attacker would have to compute hash(salt[a] . attempt[0]), where “.” denotes concatenation, compare against entry A, then hash(salt[b] . attempt[0]), compare against entry B, and so on. This defeats the “reusing” of hashes to crack multiple passwords.

Salts also make dictionary attacks and brute-force attacks for cracking large numbers of passwords much slower (but not in the case of breaking just one password). Without Salts, an attacker who is cracking many passwords simultaneously only needs to hash each password guess once and compare it to all the hashes. However, with Salts, each password will likely have a different Salt; so each guess would have to be hashed separately and compared for each Salt, which is considerably slower.

Another advantage of using Salt is that two users can choose the same string of passwords. By Salting the passwords with two random characters, the odds are that even if two accounts use the same password, no one can discover it by reading password files.

To know more about how Aujas can ensure data security and privacy of your enterprise assets, visit us here, or write to us at contact@aujas.com.