FeatureRequest: Enable scrypt to get password from file or environment variable

[dkmbw]

Hi,
i would like to use scrypt in a CICD pipeline. and the current mechanism would need stuff like expect. Is there a possibility, that a password can be used from the process environment or from a certain file which name can be shown via parameter to scrypt?

That would be really helpful.

[gperciva]

Can't this be done with -P ? Something like (untested)

cat `pass.txt` | scrypt enc -P secret.txt secret.enc

[gperciva]

We do this in our test suite: see tests/02-decrypt-reference-file.sh for example. There we use echo:

echo ${password} | scrypt dec -P $encrypted_reference_file $decrypted_reference_file

[dkmbw]

though that is indeed a possibility i could sleep sounder if scrypt would care about fetching the password. there are in personal and professional environments multitudes of failures. For me, a file (given via parameter) or environment variable (name fixed on compilation) is more sane than echoing the password into scrypt.

current examples on my mind are:

• Broken Pipes do not encrypt files now
• set -xv stuff accidentally revealing it in logs
• LC/Locales/encoding scrambles the password on echoing

And i must admit i oversaw the second sentence in the manpage for -P which said give password only ONCE. i thought i had to input it two times via stdin, therefore i thought of expect.

[gperciva]

Well, we can avoid echo. For example,

$ cd ~/src/scrypt/tests/verify-strings
$ echo "hunter2" > password.txt
$ scrypt dec -P test_scrypt_good.enc output.txt < password.txt 

Some shells will let you do

$ scrypt dec -P test_scrypt_good.enc output.txt <<< ${PASS}

but that's not standard POSIX.

Both of these options appear to be good against set -xv. I'm not certain what you mean by "broken pipes do not encrypt files now"; unfortunately I know relatively little about shells. But if you have an unencrypted file containing a password, or if you've set it as an environment variable, that seems easier than a pipe for an attacker.

Could you please elaborate on the threat(s) that you anticipate?

[dkmbw]

Of course, thank you!
First i want to adress the Broken Pipes Example:
Let's consider the following code snippet from a potential script in a CICD pipeline:

#!/bin/bash
# decrypt password.txt with masterpassword, for example:
ansible-vault decrypt password.txt
# encrypt the files
cat pass.txt | scrypt enc -P data/secret.txt data/secret.enc # any other with <, > or | is the same case
# clean up cleartext files
for i in $(data/*txt) ;
do
rm -f "${i}" ;
done
# push the encrypted files to some remote/cloud storage
./push_file_to_remote_storage.sh data

If now any pipe with scrypt FAILS, it fails silently and continues, and nothing is encrypted and nothing is pushed. there may be even shell constructs which would push cleartext files to the remote storage.
You CAN prevent this in bash with setting "set -o pipefail" which prevents the continuated working, but not everyone sets it or knows it. and that is only the "good case"

The Threats i see and fear are, that through malicious or flawed shellscripting:

• Passwords are exposed
• File are not encrypted, which are expected to be created.

And Shell scripting can be more easily obfuscated, that even with a peer review process that can slip through. If the password can be provided via file, like e.g. ansible-vault does that, too, this makes it easier to protect other files with it and people can reason more easily about the scripts which use scrypt.

[gperciva]

I'm afraid that I still don't follow. Your proposed script contains:

# encrypt the files
# any other with <, > or | is the same case
cat pass.txt | scrypt enc -P data/secret.txt data/secret.enc

How is that less safe than a theoretical

scrypt enc --password-file password.txt data/secret.txt data/secret.enc

? Is there a risk that cat will somehow fail, or that the | will dump text to the command-line instead of sending it to scrypt? I don't know of any shell which can fail like that.

[dkmbw]

Pipes can fail (for example, macosx has another pipe behaviour than linux), cat can fail, shellscripts may have bugs.

Shortly said, depending on the quality of your scripts i rather trust scrypt more to do the right thing with fetching and using the password, than shellscripts which can fail in a myriad of ways.

[cperciva]

If your shell can't reliably redirect a program's standard input (either cat foo | bar or bar < foo) then you've got way bigger issues than whether scrypt works. It's not worth cluttering up the scrypt code for such an unnecessary use case.

[gperciva]

Hi @dkmbw,

The master branch of scrypt now includes --passphrase method:arg, such as --passphrase env:VAR and --passphrase file:FILENAME, and they should be part of the next official tarball release. We're doing a final round of testing before we release scrypt 1.3.1: http://mail.tarsnap.com/scrypt/msg00267.html

[dkmbw]

That's SO cool! Thank you very much!