[Webinar] Streamline your web hosting managementRegister Today

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 813
  • Last Modified:

/etc/passwd: strange format

I know password shadowing has been in place for some time now, but my ISP seems
to have some unusual system. For a start, there appears to be no /etc/shadow, but there
is an /etc/passwd. However, the contents of this file seem partly shadowed
and partly unshadowed. Can someone suggest 1) what kind of shadowing system
the ISP may be using; 2) what the point is of including some encrypted passwords
and others replaced by *; and 3) why the encrypted passwords seem unusually
long. I'm pasting an extract from the /etc/passwd file below.


David King.

1 Solution
An * as in the password field that there is NO  VALID password.
the /etc/shadow file only used if it exists. In other case the passwd for th euser is retrieved from the passwd file itself.

Normally when you have a shadow file the password field in the passwd file contains an "X", but when the shadow file in not there the field contains the encrypted password.

This field contains 13 characters of which the last 2 (or fiorst 2) are the crypt key, and the other 11 are the encrypted password. Whenever the password field contains another number of characters all passwords will be invalid.
It means that with such a passworf field, root cannot log in.
You may want to edit that question if you don't want everyone seeing your /etc/password
root logins should be disabled at all times anyway.
You will never be able to see the contents of a shadow file unless you are root.
crypt key?????
do you mean "salt", all encrypted passwords are NOT decryptable, so there is no key.
An asterix means you can't login with that account.
Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Sorry to disappoint you but there is a 'crypt' key.

You take the value the users puts in the passwd command, you take the seed out of the shadow/passwd file, a make an encrypted key.
Then you compared your just encrypted password and compare it with the value stored in shadow/passwd file. When they match you entered a valid passwd.

This way passwords doesn't need to be encrypted, but just crypted.

If you doesn't believe it try the following:
change password into let's say pasword1
and save the encrypted password.
Then change pswd into pasword2, and again change it in to pasword1.
Now compare the first encrypted password and the last encrypted. They will 'almost' certainly differ.
If no seed would exist, you would have to get the same encrypted password if the first and third case.
It's just that I never heard of it being called a key before.
I call it "salt", maybe its my perl coming thru, where if you decide to use a non random salt, then the password will always
crypt to the same every time, I've done it.
It's always been called the "salt" as far as I know.  It goes back long before Perl.

I believe it's purpose is so that someone can't just create a big file of crypted passwords and then do a fast search.  You have to run the algorithm each time (or store 64^2 copies of each crypted password).

-- Brian
This question was awarded, but never cleared due to the JSP-500 errors of that time.  It was "stuck" against userID -1 versus the intended expert whom you awarded.  This corrects the problem and the expert will now receive these points; points verified.

Please click on your Member Profile and select "View Question History" to navigate through any open or locked questions you may have to update and finalize them.  Or if you are an EE Pro user, click the link below to select open items for your Member ID using Power Search:

This is the Community Support link, if help is needed, along with the link to All Topics which reflects many TAs recently added.

Thank you,
Moderator @ Experts Exchange

Featured Post

[Webinar] Kill tickets & tabs using PowerShell

Are you tired of cycling through the same browser tabs everyday to close the same repetitive tickets? In this webinar JumpCloud will show how you can leverage RESTful APIs to build your own PowerShell modules to kill tickets & tabs using the PowerShell command Invoke-RestMethod.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now