Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #194910 > unrolled thread

encryption

Back to article view | Back to linux.debian.user

Contents

  encryption Brian <ad44@cityscape.co.uk> - 2018-04-20 21:40 +0200
    Re: encryption Greg Wooledge <wooledg@eeg.ccf.org> - 2018-04-20 22:00 +0200
    Re: encryption David Christensen <dpchrist@holgerdanske.com> - 2018-04-21 02:10 +0200
      Re: encryption Brian <ad44@cityscape.co.uk> - 2018-04-21 17:30 +0200
        Re: encryption john doe <johndoe65534@mail.com> - 2018-04-21 17:40 +0200
          Re: encryption David Christensen <dpchrist@holgerdanske.com> - 2018-04-21 22:00 +0200
            Re: encryption john doe <johndoe65534@mail.com> - 2018-04-22 08:30 +0200
              Re: encryption David Christensen <dpchrist@holgerdanske.com> - 2018-04-22 20:30 +0200
        Re: encryption Glenn English <ghe2001@gmail.com> - 2018-04-21 19:00 +0200
          Re: encryption David Christensen <dpchrist@holgerdanske.com> - 2018-04-21 22:30 +0200
        Re: encryption David Christensen <dpchrist@holgerdanske.com> - 2018-04-21 21:50 +0200
          Re: encryption David Wright <deblis@lionunicorn.co.uk> - 2018-04-22 18:20 +0200
            Re: encryption Brian <ad44@cityscape.co.uk> - 2018-04-22 18:50 +0200
              Re: encryption David Wright <deblis@lionunicorn.co.uk> - 2018-04-23 10:50 +0200
                Re: encryption Brian <ad44@cityscape.co.uk> - 2018-04-23 13:20 +0200
                  Re: encryption David Wright <deblis@lionunicorn.co.uk> - 2018-04-24 20:50 +0200
    Re: encryption David Wright <deblis@lionunicorn.co.uk> - 2018-04-21 18:40 +0200
      Re: encryption Brian <ad44@cityscape.co.uk> - 2018-04-21 20:20 +0200
        Re: encryption David Wright <deblis@lionunicorn.co.uk> - 2018-04-21 21:00 +0200
          Re: encryption Brian <ad44@cityscape.co.uk> - 2018-04-21 21:20 +0200
            Re: encryption David Christensen <dpchrist@holgerdanske.com> - 2018-04-21 23:30 +0200
            Re: encryption David Wright <deblis@lionunicorn.co.uk> - 2018-04-22 04:30 +0200
              Re: encryption Curt <curty@free.fr> - 2018-04-22 11:20 +0200
                Re: encryption Reco <recoverym4n@gmail.com> - 2018-04-22 11:50 +0200
                  Re: encryption Brian <ad44@cityscape.co.uk> - 2018-04-22 19:10 +0200
        Re: encryption David Christensen <dpchrist@holgerdanske.com> - 2018-04-21 22:50 +0200
      Re: encryption David Christensen <dpchrist@holgerdanske.com> - 2018-04-21 22:10 +0200
        Re: encryption David Wright <deblis@lionunicorn.co.uk> - 2018-04-22 04:00 +0200
          Re: encryption Brian <ad44@cityscape.co.uk> - 2018-04-22 17:40 +0200
            Re: encryption Richard Hector <richard@walnut.gen.nz> - 2018-04-23 08:00 +0200
              Re: encryption Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2018-04-23 09:00 +0200
          Re: encryption David Christensen <dpchrist@holgerdanske.com> - 2018-04-22 20:10 +0200

Page 1 of 2  [1] 2  Next page →

#194910 — encryption

T have a script. It contains an important password.

I have encrypted the script with

  scrypt dec -t 10 /usr/local/bin/myscript

I can, of course, decrypt it with

  scrypt dec /usr/local/bin/myscript

and then execute the script.

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?

-- 
Brian

[toc] | [next] | [standalone]

#194911

On Fri, Apr 20, 2018 at 08:38:48PM +0100, Brian wrote:
> T have a script. It contains an important password.
> 
> I have encrypted the script with

I suggest storing the password in a separate file, and using file system
permissions so that only a specific user/group can read it.  Then make
the script read it from the file.

[toc] | [prev] | [next] | [standalone]

#194917

On 04/20/18 12:38, Brian wrote:
> T have a script. It contains an important password.
> 
> I have encrypted the script with
> 
>    scrypt dec -t 10 /usr/local/bin/myscript

Looking at:

http://manpages.org/scrypt


That command decrypts /usr/local/bin/myscript (and I don't know if the 
-t option is valid for decryption).


> I can, of course, decrypt it with
> 
>    scrypt dec /usr/local/bin/myscript

Assuming /usr/local/bin/myscript is ciphertext, that command will print 
the script on STDOUT.


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"?


> and then execute the script.

How are you executing a script printed on STDOUT?  A pipeline?


> 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.


Assuming the script fits into an environment variable, evaluating that 
variable in double-quoted context requires deep understanding of both 
your shell and the script (especially if the script is written for a 
different shell, and potentially a different version of the same shell). 
  If you're intent upon doing it this way, be sure to test thoroughly.


A pipeline would be more conventional-- decrypt the ciphertext and pipe 
the script to the appropriate interpreter.  Here is an example using 
Perl and the ccrypt tools:

2018-04-20 16:59:50 dpchrist@vstretch ~/sandbox/ccrypt
$ ll secret-script.pl
-rwxr-xr-x 1 dpchrist dpchrist 66 2018/04/20 16:58:19 secret-script.pl*

2018-04-20 17:00:02 dpchrist@vstretch ~/sandbox/ccrypt
$ cat secret-script.pl
#!/usr/bin/env perl
print "The important password is 'secret'\n";

2018-04-20 17:00:08 dpchrist@vstretch ~/sandbox/ccrypt
$ ./secret-script.pl
The important password is 'secret'

2018-04-20 17:00:14 dpchrist@vstretch ~/sandbox/ccrypt
$ ccencrypt --key foo secret-script.pl

2018-04-20 17:00:26 dpchrist@vstretch ~/sandbox/ccrypt
$ ll secret-script.pl.cpt
-rwxr-xr-x 1 dpchrist dpchrist 98 2018/04/20 16:58:19 secret-script.pl.cpt*

2018-04-20 17:00:30 dpchrist@vstretch ~/sandbox/ccrypt
$ ll decrypt-run-secret.sh
-rwxr-xr-x 1 dpchrist dpchrist 86 2018/04/20 16:57:27 decrypt-run-secret.sh*

2018-04-20 17:00:40 dpchrist@vstretch ~/sandbox/ccrypt
$ cat decrypt-run-secret.sh
#!/usr/bin/env sh
echo "The decryption key is 'foo'"
ccat secret-script.pl.cpt | perl

2018-04-20 17:00:51 dpchrist@vstretch ~/sandbox/ccrypt
$ ./decrypt-run-secret.sh
The decryption key is 'foo'
Enter decryption key:
The important password is 'secret'


David

[toc] | [prev] | [next] | [standalone]

#194923

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 with
> > 
> >    scrypt dec -t 10 /usr/local/bin/myscript
> 
> Looking at:
> 
> http://manpages.org/scrypt
> 
> 
> That command decrypts /usr/local/bin/myscript (and I don't know if the -t
> option is valid for decryption).

A typo. It should be "enc", not "dec".
 
> > I can, of course, decrypt it with
> > 
> >    scrypt dec /usr/local/bin/myscript
> 
> Assuming /usr/local/bin/myscript is ciphertext, that command will print the
> script on STDOUT.

Another bit of sloppiness. Redirection to a file should have been
mentioned.
 
> 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"? 
> 
> > and then execute the script.
> 
> How are you executing a script printed on STDOUT?  A pipeline?

The redirected file was executed with 'eval'. 

> > 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 that problem and the one of having trouble evaluating the
variable.
 
> Assuming the script fits into an environment variable, evaluating that
> variable in double-quoted context requires deep understanding of both your
> shell and the script (especially if the script is written for a different
> shell, and potentially a different version of the same shell).  If you're
> intent upon doing it this way, be sure to test thoroughly.
> 
> A pipeline would be more conventional-- decrypt the ciphertext and pipe the
> script to the appropriate interpreter.  Here is an example using Perl and
> the ccrypt tools:
> 
> 2018-04-20 16:59:50 dpchrist@vstretch ~/sandbox/ccrypt
> $ ll secret-script.pl
> -rwxr-xr-x 1 dpchrist dpchrist 66 2018/04/20 16:58:19 secret-script.pl*
> 
> 2018-04-20 17:00:02 dpchrist@vstretch ~/sandbox/ccrypt
> $ cat secret-script.pl
> #!/usr/bin/env perl
> print "The important password is 'secret'\n";
> 
> 2018-04-20 17:00:08 dpchrist@vstretch ~/sandbox/ccrypt
> $ ./secret-script.pl
> The important password is 'secret'
> 
> 2018-04-20 17:00:14 dpchrist@vstretch ~/sandbox/ccrypt
> $ ccencrypt --key foo secret-script.pl
> 
> 2018-04-20 17:00:26 dpchrist@vstretch ~/sandbox/ccrypt
> $ ll secret-script.pl.cpt
> -rwxr-xr-x 1 dpchrist dpchrist 98 2018/04/20 16:58:19 secret-script.pl.cpt*
> 
> 2018-04-20 17:00:30 dpchrist@vstretch ~/sandbox/ccrypt
> $ ll decrypt-run-secret.sh
> -rwxr-xr-x 1 dpchrist dpchrist 86 2018/04/20 16:57:27 decrypt-run-secret.sh*
> 
> 2018-04-20 17:00:40 dpchrist@vstretch ~/sandbox/ccrypt
> $ cat decrypt-run-secret.sh
> #!/usr/bin/env sh
> echo "The decryption key is 'foo'"
> ccat secret-script.pl.cpt | perl
> 
> 2018-04-20 17:00:51 dpchrist@vstretch ~/sandbox/ccrypt
> $ ./decrypt-run-secret.sh
> The decryption key is 'foo'
> Enter decryption key:
> The important password is 'secret'

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.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#194924

On 4/21/2018 5:20 PM, 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 with
>>>
>>>     scrypt dec -t 10 /usr/local/bin/myscript
>>
>> Looking at:
>>
>> http://manpages.org/scrypt
>>
>>
>> That command decrypts /usr/local/bin/myscript (and I don't know if the -t
>> option is valid for decryption).
> 
> A typo. It should be "enc", not "dec".
>   
>>> I can, of course, decrypt it with
>>>
>>>     scrypt dec /usr/local/bin/myscript
>>
>> Assuming /usr/local/bin/myscript is ciphertext, that command will print the
>> script on STDOUT.
> 
> Another bit of sloppiness. Redirection to a file should have been
> mentioned.
>   
>> 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"?

Here's the code I used to let a script prompt for a password:

read -s -p "Enter password: "
[ $? -ne 0 ] && exit 1

-- 
John Doe

[toc] | [prev] | [next] | [standalone]

#194940

On 04/21/18 08:38, john doe wrote:
> Here's the code I used to let a script prompt for a password:
> 
> read -s -p "Enter password: "
> [ $? -ne 0 ] && exit 1

Note that the above 'read' command will operate differently on Dash and 
on Bash:

2018-04-21 12:53:27 dpchrist@vstretch ~/sandbox/sh
$ cat read
read -s -p "Enter password: "
[ $? -ne 0 ] && exit 1
echo
echo $REPLY

2018-04-21 12:54:03 dpchrist@vstretch ~/sandbox/sh
$ dash read
read: 1: read: Illegal option -s

2018-04-21 12:54:06 dpchrist@vstretch ~/sandbox/sh
$ bash read
Enter password:
secret


Shell scripts using lowest-common denominator Bourne shell syntax are 
the most portable.  When I start getting fancy with Bash, I switch to Perl.


David

[toc] | [prev] | [next] | [standalone]

#194968

On 4/21/2018 9:58 PM, David Christensen wrote:
> On 04/21/18 08:38, john doe wrote:
>> Here's the code I used to let a script prompt for a password:
>>
>> read -s -p "Enter password: "
>> [ $? -ne 0 ] && exit 1
> 
> Note that the above 'read' command will operate differently on Dash and 
> on Bash:
> 
> 2018-04-21 12:53:27 dpchrist@vstretch ~/sandbox/sh
> $ cat read
> read -s -p "Enter password: "
> [ $? -ne 0 ] && exit 1
> echo
> echo $REPLY
> 
> 2018-04-21 12:54:03 dpchrist@vstretch ~/sandbox/sh
> $ dash read
> read: 1: read: Illegal option -s
> 
> 2018-04-21 12:54:06 dpchrist@vstretch ~/sandbox/sh
> $ bash read
> Enter password:
> secret
> 
> 
> Shell scripts using lowest-common denominator Bourne shell syntax are 
> the most portable.  When I start getting fancy with Bash, I switch to Perl.
> 

Thanks David, for pointing out that bit of code won't work in Dash!

That's one of the reasons I have redone all of my scripts to have them 
POSIX compliant while keeping portability a priority! :)

I only speak shell scripting, how would you do that in Perl?

-- 
John Doe

[toc] | [prev] | [next] | [standalone]

#194992

On 04/21/18 23:28, john doe wrote:
> On 4/21/2018 9:58 PM, David Christensen wrote:
>> On 04/21/18 08:38, john doe wrote:
>>> Here's the code I used to let a script prompt for a password:
>>>
>>> read -s -p "Enter password: "
>>> [ $? -ne 0 ] && exit 1
> I only speak shell scripting, how would you do that in Perl?

2018-04-22 11:21:56 dpchrist@vstretch ~/sandbox/perl
$ cat console-input-noecho
#!/usr/bin/env perl
use strict;
use warnings;
use Data::Dumper;
use Term::ReadKey;
print 'Please enter key: ';
ReadMode 'noecho';
my $key = ReadLine 0;
print "\nPlease confirm: ";
my $key2 = ReadLine 0;
ReadMode 'normal';
print "\n";
print Data::Dumper->Dump([$key, $key2], [qw(key key2)]);

2018-04-22 11:22:02 dpchrist@vstretch ~/sandbox/perl
$ perl console-input-noecho
Please enter key:
Please confirm:
$key = 'secret
';
$key2 = 'typo
';

David

[toc] | [prev] | [next] | [standalone]

#194929

> That's two recommendations for putting the secret in a separate file;

Or how about creating that file, copying it to a CD or USB stick,
hanging it on the wall, clearing out the directory, then mounting it
when you want to use it.

-- 
Glenn English

[toc] | [prev] | [next] | [standalone]

#194945

On 04/21/18 09:51, Glenn English wrote:
>> That's two recommendations for putting the secret in a separate file;
> 
> Or how about creating that file, copying it to a CD or USB stick,
> hanging it on the wall, clearing out the directory, then mounting it
> when you want to use it.

Moving the encrypted file a removable media reduces the amount of time 
an adversary can potentially access the file.


zerofree can eliminate the leftover bytes of the original plaintext file 
and the original encrypted file:

https://manpages.debian.org/stretch/zerofree/zerofree.8.en.html

https://packages.debian.org/search?keywords=zerofree&searchon=names&suite=all&section=all


encfs does both mounting and encryption.  It is very convenient to use 
with a USB flash drive:

https://manpages.debian.org/stretch/encfs/encfs.1.en.html

https://packages.debian.org/search?suite=all&section=all&arch=any&searchon=names&keywords=encfs


Plus, encfs uses FUSE.  FUSE file systems can only be access by the user 
who mounted them; even root is blocked.  (But, you must consider 
attackers who can log in to your UID and/or install daemons running 
under your UID.)


David

[toc] | [prev] | [next] | [standalone]

#194937

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

[toc] | [prev] | [next] | [standalone]

#194984

On Sat 21 Apr 2018 at 12:43:54 (-0700), David Christensen wrote:
> 
> On 04/21/18 08:20, Brian wrote:
> >On Fri 20 Apr 2018 at 17:07:10 -0700, David Christensen wrote:

> >> 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.

One might assume that the script could have a unencrypted option to
select between a number of "important passwords", each of which might
be a long, complex, unmemorable string, subject to frequent changes,
and (or because) exposed to the rest of the world.

OTOH the passphrase protecting the script might be a single, simple,
fixed, memorable string only exposed to users on the machine in question.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#194986

On Sun 22 Apr 2018 at 11:10:24 -0500, David Wright wrote:

> On Sat 21 Apr 2018 at 12:43:54 (-0700), David Christensen wrote:
> > 
> > On 04/21/18 08:20, Brian wrote:
> > >On Fri 20 Apr 2018 at 17:07:10 -0700, David Christensen wrote:
> 
> > >> 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.
> 
> One might assume that the script could have a unencrypted option to
> select between a number of "important passwords", each of which might
> be a long, complex, unmemorable string, subject to frequent changes,
> and (or because) exposed to the rest of the world.
> 
> OTOH the passphrase protecting the script might be a single, simple,
> fixed, memorable string only exposed to users on the machine in question.

I thought I had indicated my intention to take the advice offered and
put the important password (a master password) in a separate file and
source it from the script.

The script itself does not need encrypting if the master password is
not in it. However, I would not want the separate file unencryted
because the master password gives access to passwords for all sorts of
websites.

Users actually have to know this master password. It is a long phrase,
not too hard to memorise but tedious to type. As I have said, encrypting
the separate file with scrypt allows me to get the decryption password
down to a more user-friendly 14 characters. The prompting for the
password is done by scrypt. There is no point in multiple people having
different passwords. All users here are trusted.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#195003

On Sun 22 Apr 2018 at 17:46:12 (+0100), Brian wrote:
> On Sun 22 Apr 2018 at 11:10:24 -0500, David Wright wrote:
> 
> > On Sat 21 Apr 2018 at 12:43:54 (-0700), David Christensen wrote:
> > > 
> > > On 04/21/18 08:20, Brian wrote:
> > > >On Fri 20 Apr 2018 at 17:07:10 -0700, David Christensen wrote:
> > 
> > > >> 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.
> > 
> > One might assume that the script could have a unencrypted option to
> > select between a number of "important passwords", each of which might
> > be a long, complex, unmemorable string, subject to frequent changes,
> > and (or because) exposed to the rest of the world.
> > 
> > OTOH the passphrase protecting the script might be a single, simple,
> > fixed, memorable string only exposed to users on the machine in question.
> 
> I thought I had indicated my intention to take the advice offered and
> put the important password (a master password) in a separate file and
> source it from the script.

Sure. But the question was posed again, so I came up with one
possible reason not to prompt for the "important password".
(What made it gain that epithet hadn't been revealed at that point.)

> The script itself does not need encrypting if the master password is
> not in it. However, I would not want the separate file unencryted
> because the master password gives access to passwords for all sorts of
> websites.
> 
> Users actually have to know this master password. It is a long phrase,
> not too hard to memorise but tedious to type. As I have said, encrypting
> the separate file with scrypt allows me to get the decryption password
> down to a more user-friendly 14 characters. The prompting for the
> password is done by scrypt. There is no point in multiple people having
> different passwords. All users here are trusted.

If users are trusted, then the discussion on hiding information from
ps becomes moot, doesn't it? (That was the more interesting part of
the discussion for me.)

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#195005

On Sun 22 Apr 2018 at 18:15:00 -0500, David Wright wrote:

> On Sun 22 Apr 2018 at 17:46:12 (+0100), Brian wrote:
> > On Sun 22 Apr 2018 at 11:10:24 -0500, David Wright wrote:
> > 
> > > On Sat 21 Apr 2018 at 12:43:54 (-0700), David Christensen wrote:
> > > > 
> > > > On 04/21/18 08:20, Brian wrote:
> > > > >On Fri 20 Apr 2018 at 17:07:10 -0700, David Christensen wrote:
> > > 
> > > > >> 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.
> > > 
> > > One might assume that the script could have a unencrypted option to
> > > select between a number of "important passwords", each of which might
> > > be a long, complex, unmemorable string, subject to frequent changes,
> > > and (or because) exposed to the rest of the world.
> > > 
> > > OTOH the passphrase protecting the script might be a single, simple,
> > > fixed, memorable string only exposed to users on the machine in question.
> > 
> > I thought I had indicated my intention to take the advice offered and
> > put the important password (a master password) in a separate file and
> > source it from the script.
> 
> Sure. But the question was posed again, so I came up with one
> possible reason not to prompt for the "important password".
> (What made it gain that epithet hadn't been revealed at that point.)
> 
> > The script itself does not need encrypting if the master password is
> > not in it. However, I would not want the separate file unencryted
> > because the master password gives access to passwords for all sorts of
> > websites.
> > 
> > Users actually have to know this master password. It is a long phrase,
> > not too hard to memorise but tedious to type. As I have said, encrypting
> > the separate file with scrypt allows me to get the decryption password
> > down to a more user-friendly 14 characters. The prompting for the
> > password is done by scrypt. There is no point in multiple people having
> > different passwords. All users here are trusted.
> 
> If users are trusted, then the discussion on hiding information from
> ps becomes moot, doesn't it? (That was the more interesting part of
> the discussion for me.)

To a great extent, perhaps it does. However, wherever possible, I like
to do things "correctly" and I learnt quite a bit from the discussion.
The password not showing up in the 'ps -f' output was intriguing and my
conjecture that the mpw program was sanitising the command line output
didn't sound convincing to me.

Then I came across

https://unix.stackexchange.com/questions/78757/securely-feeding-a-program-with-a-password

 @Dor Something like echo 'password=p4ssw0rd' >>mysql.cnf is safe,
 because echo is a built-in, so the password doesn't appear on the
 command line of any process. A here document is also safe.
 – Gilles Jun 9 '13 at 22:32

'eval' is a bash builtin, so it looks as though I have an explanation.

mpw will also accept a password via a file decriptor; something else
to explore when I get to finding out what one is.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#195050

On Mon 23 Apr 2018 at 12:10:15 (+0100), Brian wrote:
> On Sun 22 Apr 2018 at 18:15:00 -0500, David Wright wrote:
> 
> > On Sun 22 Apr 2018 at 17:46:12 (+0100), Brian wrote:
> > > On Sun 22 Apr 2018 at 11:10:24 -0500, David Wright wrote:
> > > 
> > > > On Sat 21 Apr 2018 at 12:43:54 (-0700), David Christensen wrote:
> > > > > 
> > > > > On 04/21/18 08:20, Brian wrote:
> > > > > >On Fri 20 Apr 2018 at 17:07:10 -0700, David Christensen wrote:
> > > > 
> > > > > >> 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.
> > > > 
> > > > One might assume that the script could have a unencrypted option to
> > > > select between a number of "important passwords", each of which might
> > > > be a long, complex, unmemorable string, subject to frequent changes,
> > > > and (or because) exposed to the rest of the world.
> > > > 
> > > > OTOH the passphrase protecting the script might be a single, simple,
> > > > fixed, memorable string only exposed to users on the machine in question.
> > > 
> > > I thought I had indicated my intention to take the advice offered and
> > > put the important password (a master password) in a separate file and
> > > source it from the script.
> > 
> > Sure. But the question was posed again, so I came up with one
> > possible reason not to prompt for the "important password".
> > (What made it gain that epithet hadn't been revealed at that point.)
> > 
> > > The script itself does not need encrypting if the master password is
> > > not in it. However, I would not want the separate file unencryted
> > > because the master password gives access to passwords for all sorts of
> > > websites.
> > > 
> > > Users actually have to know this master password. It is a long phrase,
> > > not too hard to memorise but tedious to type. As I have said, encrypting
> > > the separate file with scrypt allows me to get the decryption password
> > > down to a more user-friendly 14 characters. The prompting for the
> > > password is done by scrypt. There is no point in multiple people having
> > > different passwords. All users here are trusted.
> > 
> > If users are trusted, then the discussion on hiding information from
> > ps becomes moot, doesn't it? (That was the more interesting part of
> > the discussion for me.)
> 
> To a great extent, perhaps it does. However, wherever possible, I like
> to do things "correctly" and I learnt quite a bit from the discussion.
> The password not showing up in the 'ps -f' output was intriguing and my
> conjecture that the mpw program was sanitising the command line output
> didn't sound convincing to me.
> 
> Then I came across
> 
> https://unix.stackexchange.com/questions/78757/securely-feeding-a-program-with-a-password
> 
>  @Dor Something like echo 'password=p4ssw0rd' >>mysql.cnf is safe,
>  because echo is a built-in, so the password doesn't appear on the
>  command line of any process. A here document is also safe.
>  – Gilles Jun 9 '13 at 22:32
> 
> 'eval' is a bash builtin, so it looks as though I have an explanation.

Yes, though I wasn't impressed with the bit about overwriting arguments.
Seems like a bit of a hack and another potential race.

> mpw will also accept a password via a file decriptor; something else
> to explore when I get to finding out what one is.

https://www.computerhope.com/unix/bash/exec.htm

is a fun page with some examples (the one using fd 3 and read is a
construction I use a lot in .bashrc). And this builds on:

https://www.computerhope.com/unix/ubash.htm#redirection

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#194927

On Fri 20 Apr 2018 at 20:38:48 (+0100), Brian wrote:
> T have a script. It contains an important password.

If you   cat /usr/local/bin/myscript   do you see your important
password on the screen?

> I have encrypted the script with
> 
>   scrypt [enc] -t 10 /usr/local/bin/myscript
> 
> I can, of course, decrypt it with
> 
>   scrypt dec /usr/local/bin/myscript
> 
> and then execute the script.
> 
> 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 so, then won't the password be revealed by ps while eval is
evaluating it?

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#194933

On Sat 21 Apr 2018 at 11:36:05 -0500, David Wright wrote:

> On Fri 20 Apr 2018 at 20:38:48 (+0100), Brian wrote:
> > T have a script. It contains an important password.
> 
> If you   cat /usr/local/bin/myscript   do you see your important
> password on the screen?

With the unencrypted file - yes. With the encrypted file -no.
> 
> > I have encrypted the script with
> > 
> >   scrypt [enc] -t 10 /usr/local/bin/myscript
> > 
> > I can, of course, decrypt it with
> > 
> >   scrypt dec /usr/local/bin/myscript
> > 
> > and then execute the script.
> > 
> > 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 so, then won't the password be revealed by ps while eval is
> evaluating it?

I do not know the most efficacious way to see the ps output in real time
as eval runs. With a bit of trial and error (scrypt is slow enough to
switch to another console and use ps) I captured

23266 pts/7    R+     0:00 mpw -q -F     -M                                       -t     railcard

in its output. mpw is the basic command executed by myscript. Switches
are shown but not parameters. -M is the very important one. The gap
would be occupied by the passphrase.

Is it possible that ps output does not show parameters to switches?

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#194935

On Sat 21 Apr 2018 at 19:14:06 (+0100), Brian wrote:
> On Sat 21 Apr 2018 at 11:36:05 -0500, David Wright wrote:
> 
> > On Fri 20 Apr 2018 at 20:38:48 (+0100), Brian wrote:
> > > T have a script. It contains an important password.
> > 
> > If you   cat /usr/local/bin/myscript   do you see your important
> > password on the screen?
> 
> With the unencrypted file - yes. With the encrypted file -no.
> > 
> > > I have encrypted the script with
> > > 
> > >   scrypt [enc] -t 10 /usr/local/bin/myscript
> > > 
> > > I can, of course, decrypt it with
> > > 
> > >   scrypt dec /usr/local/bin/myscript
> > > 
> > > and then execute the script.
> > > 
> > > 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 so, then won't the password be revealed by ps while eval is
> > evaluating it?
> 
> I do not know the most efficacious way to see the ps output in real time
> as eval runs. With a bit of trial and error (scrypt is slow enough to
> switch to another console and use ps) I captured
> 
> 23266 pts/7    R+     0:00 mpw -q -F     -M                                       -t     railcard
> 
> in its output. mpw is the basic command executed by myscript. Switches
> are shown but not parameters. -M is the very important one. The gap
> would be occupied by the passphrase.
> 
> Is it possible that ps output does not show parameters to switches?

Not AFAIK. Here, I can see lines in the list such as:

 1247 ?    Ss 0:00 wpa_supplicant -B -i wlp2s0 -c /var/lib/wicd/configurations/44xxfcxxxxxx -Dwext
 1706 tty1 S  0:00 xterm -geometry 110x38+0+0 -fn neep-iso10646-1-18 -xrm *Page: 3 1

As you can see, I've mangled the MAC of my router that would be revealed otherwise.

And I wouldn't like to rely on winning a race with ps to avoid capture
of information exposed in my command lines.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#194936

On Sat 21 Apr 2018 at 13:54:03 -0500, David Wright wrote:

> On Sat 21 Apr 2018 at 19:14:06 (+0100), Brian wrote:
> > On Sat 21 Apr 2018 at 11:36:05 -0500, David Wright wrote:
> > 
> > > On Fri 20 Apr 2018 at 20:38:48 (+0100), Brian wrote:
> > > > T have a script. It contains an important password.
> > > 
> > > If you   cat /usr/local/bin/myscript   do you see your important
> > > password on the screen?
> > 
> > With the unencrypted file - yes. With the encrypted file -no.
> > > 
> > > > I have encrypted the script with
> > > > 
> > > >   scrypt [enc] -t 10 /usr/local/bin/myscript
> > > > 
> > > > I can, of course, decrypt it with
> > > > 
> > > >   scrypt dec /usr/local/bin/myscript
> > > > 
> > > > and then execute the script.
> > > > 
> > > > 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 so, then won't the password be revealed by ps while eval is
> > > evaluating it?
> > 
> > I do not know the most efficacious way to see the ps output in real time
> > as eval runs. With a bit of trial and error (scrypt is slow enough to
> > switch to another console and use ps) I captured
> > 
> > 23266 pts/7    R+     0:00 mpw -q -F     -M                                       -t     railcard
> > 
> > in its output. mpw is the basic command executed by myscript. Switches
> > are shown but not parameters. -M is the very important one. The gap
> > would be occupied by the passphrase.
> > 
> > Is it possible that ps output does not show parameters to switches?
> 
> Not AFAIK. Here, I can see lines in the list such as:

Then I do not understand why paramters are not shown. Maybe they come
later in the output? I can forsee a few sleepness nights trying to
figure this out. :)

At this juncture it appears I should have no worries about ps revealing
the secret.

>  1247 ?    Ss 0:00 wpa_supplicant -B -i wlp2s0 -c /var/lib/wicd/configurations/44xxfcxxxxxx -Dwext
>  1706 tty1 S  0:00 xterm -geometry 110x38+0+0 -fn neep-iso10646-1-18 -xrm *Page: 3 1
> 
> As you can see, I've mangled the MAC of my router that would be revealed otherwise.
> 
> And I wouldn't like to rely on winning a race with ps to avoid capture
> of information exposed in my command lines.

I am not after winning any races but (seeing as you brought the issue
up) knowing whether ps sees my secret and how to go about finding that
out.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web