Securely passing password to openssl via stdin

Question

We know we can encrypt a file with openssl using this command:

openssl aes-256-cbc -a -salt -in twitterpost.txt -out foo.enc -pass stdin

The password will be read from stdin. As such, to provide the password beforehand, all we need do is prepend

echo "someGoodPassword" |

to the above command. My question is: How can I do this more securely? The above method doesn't look secure enough.

I'd appreciate some comments about this so I can understand this issue better.

Answer 1

Put password into bash or other script file, and make 600 permissions for it. That will allow only you to view the file, and password will no be revealed anywhere.

Answer 2

You can use several methods for pass through the password: https://www.openssl.org/docs/man1.0.2/apps/openssl.html#PASS-PHRASE-ARGUMENTS

As @Petesh said, the root can read everything!

Therefore, if you write down the password into any common(!) file, e.g.

• into a temporary file with any safe permission
• or into the script what does do your echo trick into a pipe

the root user could find this!

Don't prefer to use everything what available via /proc (e.g. by the ps)

So, do not use...

openssl aes-256-cbc ... -passin 'pass:someGoodPassword'

or

PASSWORD='someGoodPassword'
openssl aes-256-cbc ... -passin 'env:PASSWORD'`

The best solution

• Avoid storing passwords in plain text on your system (e.g. use password manager)

• Pass through passwords to openssl via pipe/fifo:

  password_manager get_password | openssl aes-256-cbc ... -passin 'stdin'
  

  or

  # https://stackoverflow.com/a/7082184/1108919
  password_manager get_password >&3
  openssl aes-256-cbc ... -passin 'fd:3'
  

  or

  openssl aes-256-cbc ... -passin "file:<(password_manager get_password)"
  

Answer 3

pretty much any mechanism you use will be snoopable by root, so bear this in mind.

The echo option, will display in the 'ps' listings, making it vulnerable to ordinary users snooping and finding the password.

You can use -pass file:filename to use a file, so you can use:

sumask=$(umask)
umask 077
rm -f passfile
cat >passfile <<EOM
someGoodPassword
EOM
umask $sumask

this creates the file, unreadable by other accounts (but still readable by root). One assumes that the script is being used once only to create the passfile, as if you repeat the process, it tends to be in a file, and therefore you need to chmod go-rwx the file to make it unreadable by other users.

then you use:

openssl aes-256-cbc -a -salt -in twitterpost.txt -out foo.enc -pass file:passfile

to perform the encryption, using the pre-created password file.

Other mechanisms are -pass env:ENVVAR for using an environment variable (again getting it in there without revealing it is the trick)

Answer 4

If I understand right, your concert about

$ echo "someGoodPassword" | openssl (...) -pass stdin

is that the password will be visible in the process list to all users for some short amount of time. That can be easily worked around with bash's <<< redirection (will not work in plain old POSIX shell, though):

$ openssl (...) -pass stdin <<<"someGoodPassword"

This construct supports variable interpolation (<<<"$password") and the command output can be piped further or redirected to file as usual.

Answer 5

Short version

Use a named pipe.

openssl aes-256-cbc -a -salt -in twitterpost.txt -out foo.enc -pass file:<( echo -n "someGoodPassword" )

Long version

Use a named pipe. You can create it in bash with

<( *output* )

e.g.

<( echo -n "content" ) # without -n echo will add a newline

It will open a named pipe, usually a FIFO queue, and you will see on the process list something like

/dev/fd/63

It will be readable only by the current user and will be automatically closed after it has been read, so you don't have to worry about permissions and cleaning up the disk (the pipe would close if the program crash, while a file created by you as suggested in another answer would stay on disk).

This way it will close in the fastest way possible, just after the command read it and without waiting for it to finish his task (I just did a test: encrypt some gigabytes and try to read the named pipe (it's visible in the process list): the named pipe closes instantaneously even if openssl takes ages to encrypt).

About your comments

If the computer has been compromised by a 2nd app to obtain this password, then the user has some serious security issues to worry about. Actually, it could be some software specifically designed to attack my own software

If your computer has been hacked and the attacker has your same user rights, you're done for. At example the attacker may easily modify your .bashrc to alias openssl so that it starts an hypotetic "evil-openssl" that copy your password and data before handling everything to the real openssl, leaving you with your false sense of security.

That said, I'm not a security expert, so if anyone want to downvote me into oblivion (and tell me why), you're welcome.