Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We know that users' passwords are saved in /etc/passwd, but in an encrypted way, so even the root can't see them:


As shown above, :x: represents the password.

Is there a way (possible configuration) to save the password in the /etc/passwd in clear text and such that the root can see them?

share|improve this question
No. And that's a feature. There's also no real reason for it since the root account does not need a user's password to access their files. Under what circumstance would you want this? – HalosGhost Jul 19 '14 at 18:37
I'm just curious about this, why can't the admin (the root) of the system see the passwords of other users? – user78050 Jul 19 '14 at 18:39
@user78050 because the root user has no reason to know the passwords of other users, and it would be a major security risk to allow them to do so. – David Z Jul 19 '14 at 18:41
Because it violates the simplest security principle in the business: "never store passwords in plain-text." When security is done well, only the user should know their password, no one else. Plus, there is absolutely no reason to do this. I cannot think of a single administrative situation where it would help a root user to know another user's password. – HalosGhost Jul 19 '14 at 18:41
Use the MD5 "encryption method" then crack the passwords using rainbow tables. – Cristian Ciupitu Jul 19 '14 at 19:26
up vote 49 down vote accepted

The other two answers have told you—correctly!—that this is a Bad Idea™. But they've also told you its hard to do, requiring changing a bunch of programs.

That's not true. It's very easy. You only need to change one or two configuration files. I feel its important to point this out, because you should be aware of it when logging into systems you don't control. These won't actually put a plain-text password in /etc/passwd or /etc/shadow, it'll go into a different file. Note I haven't tested these, as I'd rather not have my password in plain text.

  1. Edit /etc/pam.d/common-password (to catch on password changed) or /etc/pam.d/common-auth (to catch on login) and add in … pam_exec expose_authtok log=/root/passwords /bin/cat

  2. Edit both of those, and switch from pam_unix to pam_userdb with crypt=none. Alternatively, you could put it only in common-password (leaving pam_unix as well) to just record passwords when they're changed.

  3. You could remove the shadow (as well as any strong hash options) option from pam_unix to disable the shadow file, and go back to traditional crypt passwords. Not plain text, but John the Ripper will fix that for you.

For further details, check the PAM System Admin Guide.

You could also edit the source code of PAM, or write your own module. You'd only need to compile PAM (or your module), nothing else.

share|improve this answer
This should be the accepted answer, because it answers the main question. – erik Jul 19 '14 at 23:10
I suppose the plain text passwords are written to /root/passwords. – Faheem Mitha Jul 19 '14 at 23:50
@erik It's the asker's prerogative to pick whichever answer he/she finds most helpful as the accepted answer. It's probably a good thing that OP found "don't do that!" the most helpful… Also, to be clear, this isn't the only way to steal passwords on a compromised or maliciously administered system. So you can't just look at the PAM config to determine you're safe. – derobert Jul 20 '14 at 2:35
This is rather assuming the distro is using PAM, by no means all of them do. – Vality Jul 20 '14 at 17:06
@msw I answered because its apparently a common belief that running a Linux box with clear-text passwords is hard (Bobby, to his credit, fixed his answer; Anthon's still makes it sound hard). That's a dangerous belief, as it encourages password re-use. If I'd just posted an answer "actually, its easy, you edit a file or two, but I won't tell you" then no one would have believed that. Why listen to me over the (at the time) much higher voted, more thorough answers? Making the point requires saying how to do it. (Though, they're not copy & paste examples. Thought's still required to use.) – derobert Jul 21 '14 at 15:01

Oh dear, okay, let's start at the very beginning...

We know that users' passwords are saved in /etc/passwd, but in an encrypted way

No, they have been stored in /etc/passwd, and that was quite some time ago. Today passwords are stored in a so-called shadow file, most of the time /etc/shadow.

but in an encrypted way, so even the root can't see them:

I know it's sometimes used interchangeably, but hashing is not encryption. Encryption is by its very definition reversible, meaning you can translate the encrypted thing back into its cleartext form. Hashing is designed to be not reversible in any way (except brute force). The original cleartext form of something that is hashed is not supposed to be recoverable.

Passwords in the shadow file are stored as hashes.

as shown above :x: represent the password

The x in this case is only a placeholder for the legacy password field. The x means that the password can be found in the shadow file.

Is there a way (possible configuration) to save the password in the /etc/passwd in clear text and such that the root can see them?

Yes, this is indeed possible, but is not a good idea for some reasons. Derobert's answer explains a rather simple way to do it.

But why is it not a good idea? Well, for a simple but very important reason: security. I suggest to read these questions:

But to sum it up, assume the following: There is a server in a company, all user accounts are secured by their passwords and the data in these user accounts is encrypted with the same password. A cracker from the outside gains access to the server, but they can't access any of the important data because that is still encrypted in the user accounts.

Now assume the passwords would be stored in plain text. The cracker would suddenly have access to everything, because the passwords can be read. But if they're stored as hashed values, they are close to useless to anyone except people with a lot of resources to do a brute-force attack.

share|improve this answer
In OP's defense regarding encryption and hashing, the crypt man page from glibc says: «If salt is a character string starting with the characters "$id$" followed by a string terminated by "$": $id$salt$encrypted then instead of using the DES machine, id identifies the encryption method used and this then determines how the rest of the string is interpreted». – Cristian Ciupitu Jul 19 '14 at 19:20
Interesting, but doesn’t answer the main question, as derobert’s answer does. – erik Jul 19 '14 at 23:11
@erik Sometimes the right answer to a question is “don't do it”, even when the thing is technically possible. This is one of those times. – Gilles Jul 19 '14 at 23:44
I suggest changing this line: "No, there isn't a way except changing many applications and the way they work." That leaves the impression that it's not easy (or at least easy to do something functionally equivalent). – derobert Jul 20 '14 at 2:38
@Bobby This is an excellent response, but not an excellent answer. To make it an excellent answer you should change the part about it being "not easily possible", because it clearly is, as shown in derobert's answer. – anthropomorphic Jul 20 '14 at 2:53

First of all the encrypted passwords are not in /etc/passwd, but they are in /etc/shadow. One of the reasons for this is that /etc/passwd is publicly readable (so you can e.g. find the GECOS field information for another user), and, especially with older encryption schemes could allow brute force attacks against the encrypted password.

To just store the passwords in plain text, is not necessary and would require updates to the password program and libraries reading the /etc/shadow information to check for valid passwords. And then you have to hope that all utilities use shared libraries to access that information instead of being statically linked against something that doesn't understand plain text password storage.

If this would be an option in the configuration of a setup, then there would always be stupid people that would switch it on inappropriately. And while they are still working on CRT screens and broadcast this in a way that it can be easily picked up from outside their building, while they are looking at the information.

Aside from that, people tend to use the same or similar password on multiple systems, so that is not a good idea for any passwords to be human readable. As some sysadmin could retry theirs on other systems (s)he knows the user has an account.

There must be more interesting things, the workings of can be investigated on your system.

share|improve this answer
/etc/shadow doesn't store encrypted passwords, it stores password hashes. Yes, the function is called crypt, and the man page says “encrypted”, but if you call a fish a bicycle, that doesn't give it wheels. Note that it would be possible to make /etc/shadow store passwords in a different format without recompiling any programs (at least on Linux and Solaris): authentication methods are always linked dynamically. Storing passwords as plain text would be a terrible idea but is possible with a bit of work. – Gilles Jul 19 '14 at 23:43
@gilles I just reused the OPs terminology, but you are right that hash is a more appropriate term. – Anthon Jul 20 '14 at 6:30

The basic reason (of why this is a bad idea) is that no user (root, admin or other) should ever have access to another's user password.

Simply because the password is a means of authentication. If I know some other user's password, I know their credentials (username + password), so I can login as that user, impersonating him (or her or it.)

Any action I do when logged in as that user, the other user will be held responsible for. And that is not how authentication should work.

The actions can be disastrous, like deleting a whole bunch of important files, erasing hard disks, erasing backups, shutting down nuclear power plans, etc.

Or just illegal. Imagine a bank institution where I (the admin) have access to all passwords. Using the cashier's password I can order a move of a million dollars from the president's bank account to the window cleaner's bank account. Then use the cashier's superior password to approve the transaction. Then approve a check from the window cleaner's account to my own off-shore bank account.

Then I go for long vacation in the Bahamas ...

In that view, the hashing of the passwords and the use of separate shadow files can be seen as a means to enforce this rule (no user should be able to impersonate another).

And as @Miral's commented*, there is the exception of su which while allowing impersonation (and kinds of throws off the argument above), is also keeping a log of its use (so it changes the rules to "only admins can impersonate others but a log is kept").

* The bank example was probably not the best. In any environment where security is crucial, more means of authentication and authorization are usually required than just one password.

share|improve this answer
One flaw with this argument is that the root user can impersonate any other user on the system anyway, without having to know their password. As easy as su otheruser. – Miral Jul 21 '14 at 7:07
@Miral you are right, I did not consider this. And although the use of su is logged, su does not keep a record of what is actually done while a user impersonates another. And a malicious root can always alter the logs to hide the actions from future investigators. – ypercubeᵀᴹ Jul 21 '14 at 7:48

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.