Linux & UNIX /etc/passwd file structure

As a part of one my group tasks in university, we decided to fully understand the Linux passwd file in order to complete our objectives. Whilst researching, I discovered there was more than one password file (read on); it was difficult to distinguish the purpose and difference between the two without having many tabs open. So I created a small document in more-or-less bullet point form, which can hopefully become a useful reference for someone else, not just me.

Prior to [and around] 1990, most distributed UNIX systems solely used the /etc/passwd file and all its features – one of the features was that it stored all user passwords (in encrypted form) in there, along with various other information too.

The below image illustrates the typical format of a user’s account entry in the /etc/passwd file.

passwd file structure

  1. Username
  2. The encrypted password: If the value is “x” then that means the value is stored in the /etc/shadow file (read on).
    • Else, a user’s password is encoded using a modified version of DES and a two-character Salt value, ranging values from 0-4096. The modified version of DES (used in the crypt function), was a one-way hashing algorithm.
  3. User ID: Value 0 is reserved for root, values 1-99 are for predefined accounts. 100-999 are also reserved for system administrator and system users/groups.
  4. Group ID: A value to represent which group the user belongs to on system. Further information stored in /etc/group
  5. GECOS/User Info:
    1. User’s full name
    2. Building and room number or contact person
    3. Office telephone number
    4. Any other information (page number, fax, etc.)
  6. Home Directory: The absolute path to the user’s home directory. This is also the default location the shell will leave the user when opening the terminal.
  7. Command/shell: The absolute path to the default shell used for that user.

In [near-]1992, UNIX distributions were issued with the new security feature of the /etc/shadow file, which replaced /etc/passwd’s responsibility of storing encrypted copies of user account’s passwords. The below image illustrates the typical format of a user’s entry in the /etc/shadow file.

shadow file structure

  1. Username
  2. The encrypted password
    1. The $1$ denotes that the MD5 algorithm was used. $2a$ for blowfish, $5$ for SHA-256 and $6$ for SHA-512. NB: rounds can be varied for Blowfish and SHA-256/512 by using $6$rounds=n%.
    2. The first string between the subsequent $’s represents the salt
    3. The subsequent string (without a trailing $, instead with a tailing 🙂 is the encrypted password
  3. Last password change: Days since Jan 1st 1970 (epoch)
  4. The number of days left until user is allowed to change password
  5. The number of days the password is valid for (then user is forced to change password)
  6. The number of days (prior to expiration) to issue a warning to the user of password expiration
  7. The number of days after password expiration (showing account inactivity)
  8. The number of days since epoch that the login may no longer be used
  9. Supposedly reserved…

Why was /etc/shadow implemented?

The /etc/passwd file was originally designed as the all-purpose user file, where it contains all relevant user information (including passwords). However, there was one security exploit that made all local and network-based users vulnerable when storing their passwords in the /etc/passwd’s file.

Even though the passwords were encoded with a one-way hash function, making it near impossible to manually revert back to its original state, the permissions of the file itself were so that everyone on the same system (or had remote access to that system) were able to read the /etc/passwd file. Thus giving them clear sight of the encoded passwords; allowing malicious users to simply extract the hashes and perform brute force attacks, as Triple-DES became easier far less resilient to repetitive hashing as hardware power progressed through time.

A natural and immediate response to this security issue, would just be to simply adjust the access permission on the /etc/passwd file, right? No, this was not practical due to the global dependency of this file by various utilities and programs that checked a user’s permission levels, which commonly read User ID’s and Group ID’s. Therefore, the implementation of the shadow file resolves this issue by keep the encoded passwords in a separate file which can only be read (nothing more) by the root user.

Useful website

http://www.functions-online.com/crypt.html

Bibliography

Conorich, D. (2013). UNIX passwords. Information Systems Security, 1065898X, Spring98, Vol. 7, Issue 1. [online] Retrieved from: http://ehis.ebscohost.com/eds/detail?sid=d2b73144-e7fc-430c-9f02-c87915844a42%40sessionmgr15&vid=5&hid=101&bdata=JnNpdGU9ZWRzLWxpdmU%3d#db=bth&AN=947666 [Accessed: 7 Nov 2013].

Fiamingo, F. (2013). Unix System Administration. [online] Retrieved from: http://www.lagmonster.org/docs/unix/sysadm-238.html [Accessed: 7 Nov 2013].

Garfinkel, S., Schwartz, A. and Spafford, G. (2003). Practical Unix & Internet Security, 3rd Edition. O’Reilly.

Hernberg, P. and Lambrechts, F. (2000). How User Information is Stored on Your System. [online] Retrieved from: http://www.tldp.org/HOWTO/User-Authentication-HOWTO/x71.html [Accessed: 7 Nov 2013].

IBM (n.d.). /etc/passwd File (AIX Documentation). [online] Retrieved from: http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.files/doc/aixfiles/passwd.htm [Accessed: 7 Nov 2013].

Unknown. (2006, Feburary 22nd). Understanding /etc/passwd File Format. NixCRAFT FAQ, [web log] Retrieved from: http://www.cyberciti.biz/faq/understanding-etcpasswd-file-format/ [Accessed: 7 Nov 2013].

Unknown. (2009, 1st October). Linux: hash algorithms for passwords inside /etc/shadow. Run like Hell, [web log] Retrieved from: http://dietrichschroff.blogspot.co.uk/2009/10/linux-hash-algorithms-for-passwords.html [Accessed: 7 Nov 2013].

Wikipedia (2013). passwd. [online] Retrieved from: https://en.wikipedia.org/wiki/Passwd [Accessed: 7 Nov 2013].

One Comment:

  1. Awesome, thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *