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

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 2

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.