Re: encryption
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.
Reply to: