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.
