How to make user passwords shown as a clear text in Linux?

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

jane:x:501:501::/home/jane:/bin/bash
fred:x:502:502::/home/fred:/bin/bash

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?

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

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.

Method 2

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:

• What is a good analogy to explain why passwords should be hashed to a layman?
• How to securily hash passwords?
• Why should I hash passwords?
• Why is password hashing considered so important?
• Why are hash functions one way? If I know the algorithm, why can’t I calculate the input from it?

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.

Method 3

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.

Method 4

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.}

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0