[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: encryption



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.


Reply to: