Re: encryption
On 04/21/18 08:20, Brian wrote:
On Fri 20 Apr 2018 at 17:07:10 -0700, David Christensen wrote:
On 04/20/18 12:38, Brian wrote:
T have a script. It contains an important password.
I have encrypted the script [using scrypt] ...
I ... decrypt it ...
[and redirect the plaintext] to a file ...
The redirected file was executed with 'eval'.
In general, evaluating a script is not the same as piping a script to a
shell program. In the former case, I believe the script runs within the
caller's environment. This means the script can modify the caller's
environment. In the latter case, I believe the script gets its own,
isolated environment (possibly with security enhancements, depending
upon the shell program). I would choose the latter.
>> As scrypt is going to prompt you for a passphrase anyway, why don't
>> you leave the script unencrypted and revise it to prompt for the
>> "important password"?
Please comment.
The two last steps have been combined into
DECRYPT=$(scrypt dec /usr/local/bin/myscript) && eval "$DECRYPT"
Should I have any more concerns with this command than I have with the
two-step process?
If the script is too big to fit in an environment variable, that would be a
problem.
That passed through my mind. The script is 73 lines and, fortunately.
does fit. Putting the secret in a separate file is, however, a good way
to avoid [the problem of exceeding the size limit of an environment variable] and the one of having trouble evaluating the
variable.
In general, evaluating a file and assigning the result into a variable
is not the same as reading a file and assigning the contents into a
variable. I would choose the latter.
Moving the important password from an encrypted script to a plaintext
file protected only by Unix file system permissions is more
conventional, but provides less security.
The conventional solution is to prompt the user for passwords and to
only store hashes on the computer (for verifying the passwords entered).
I prototyped with gpg but ended up with scrypt because it is memory-hard
and slow to decrypt. That seemed to be an advantage; the decryption
passphrase could afford to be shorter and not give users here too much
to remember or type. I'll certainly take a look at what you suggest,
though.
That's two recommendations for putting the secret in a separate file;
I'll follow the advice. My concern was missing some important security
implication but that doesn't appear to be the case. Thanks to Greg
Wooledge and yourself.
My recommendation is to prompt users for passwords.
If you have a program which requires a password to run, you want
multiple people to be able to run that program, but you want each person
to have a different password, the best solution would be to add
multi-user password support to the program.
David
Reply to: