Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm reading "Reliably Deploying Rails Applications"

Regarding defining users to be set up by Chef, it says:

“Next we need to define users, inside data_bags/users copy the file deploy.json.example to deploy.json.

Generate a password for your deploy user with the command:

openssl passwd -1 "plaintextpassword"

And update deploy.json accordingly.”

My question is, what is the purpose of openssl passwd? Is it just to generate a strong password? Would it be just as good if I typed in random characters?

And then, what is my 'actual' password? The plain text version, or the encrypted version? Do I need to save a copy of both to my password manager?

UPDATE:

Yes, I have read the manual. And yes, I understand that it generates an md5 encrypted version of my password. My question is more about why you'd use it, as opposed to using a very secure random string of characters that you make up yourself (or generate with a password generator).

One benefit I could think of is that you could type a rememberable password, and run it through openssl passwd -1 "plaintextpassword" every time you need to enter it. So you'd kind of have the best of both worlds in terms of an easy to remember password, and a secure, random password. And running the rememberable/plain text version through `openssl passwd -1 every time you need it would save you having to store the encrypted version of the password and type / paste that in every time you need to enter your password.

Is that the only benefit? If not, what are the others?

share|improve this question
    
man 1SSL passwd –  Richard Salts Feb 11 at 1:25

2 Answers 2

The purpose of that command is to feed your password through a one-way hashing algorithm (-1 outputs MD5). What that gets you is a string that's derived from your password cryptographically, but cannot be used to find your password on its own if an attacker gets their hands on the hashed version (theoretically - there's a salt included which helps against rainbow tables, but an attacker can still brute force effectively against it).

Your password being run thorough the hashing function will always result in the same hash, which can then be compared by the server to the stored hash to verify that you have the same password as was run through the openssl command.

share|improve this answer
    
Thanks. My question is more: Given that all I store in deploy.json is the encrypted version, do I have any use for the non-encrypted version? When I type my password, don't I have to use the encrypted version anyway? Is the purpose of using this method simply so that I could have a rememberable password, and then run it through openssl passwd every time I wanted to use it, as opposed to typing the encrypted version out? –  joshua.paling Feb 11 at 2:22
    
I've updated my question with a little more explanation of what I'm after. –  joshua.paling Feb 11 at 2:31
    
@joshua.paling The benefit of the MD5 password is that you can authenticate to the server using the original password, without the server storing the original password in plain text. You'll be using your original password to authenticate to the application, which will then hash it with MD5 and compare to the stored MD5. –  Shane Madden Feb 11 at 3:10
up vote 2 down vote accepted

After some chat on the #chef IRC channel, here's what I ultimately needed to know. Most of it is actually peripheral info, rather than openssl passwd specific, but anyway...

Chef users the standard adduser command (http://linux.die.net/man/8/adduser) for adding users. That command accepts the password already encrypted - Hence why you need to store an encrypted version (generated by openssl passwd -1 "plaintextpassword") in your data_bags/users/deploy.json.

So, your plain-text password is the 'real' password. But because the adduser command expects the password you pass it to be already encrypted, it's the encrypted version that you need to store in data_bags/users/deploy.json

That works well, because you definitely wouldn't want to store a plain-text password in data_bags/users/deploy.json!

Coming back to my original questions:

What is my 'actual' password? The plain text version, or the encrypted version?
The plain text version is your real one.

Do I need to save a copy of both to my password manager? No. You only store your plain-text version. You use that whenever you want to log in. The system then encrypts that, and compares it to the encrypted version that it has stored for your account.

What is the benefit / purpose of openssl passwd?

There is no 'benefit' as such. It's simply required because the adduser command will expect the password it's given to be already encrypted.


Having said all that, apparently it's much better to not sore a password at all in data_bags/users/deploy.json, and only allow access via SSH Keys.

It's not considered a good practice to store even an encrypted version of your password in data_bags/users/deploy.json because Linux password encryption has such a bad track record. (edit: read comments below for a better explanation)

share|improve this answer
    
because Linux password encryption has such a bad track record That's not really an accurate representation - it's more a problem of giving an attacker access to your hashed password, which they can then take and brute force (to attempt to recover your original password) on their own system - and since MD5 is a comparatively fast to compute algorithm, an attacker might be able to make hundreds of thousands or millions of guesses at your password per second. MD5 is an industry standard, and it's not recommended for use these days due to weaknesses which are not specific to Linux. –  Shane Madden Feb 11 at 3:55
    
Not having a password attached to the user at all could have some security advantages, but also has potential drawbacks - you will likely want to be able to SSH with a key then sudo with a password. Since you're just setting the user account's hashed password in the shadow file, consider storing it using a stronger algorithm - see here. –  Shane Madden Feb 11 at 4:00
    
Thanks, that's a big help. –  joshua.paling Feb 11 at 4:18

Your Answer

 
discard

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.