On Tue, 10 Dec 2019 21:43:55 +0000 Brian <a...@cityscape.co.uk> wrote:
> On Mon 09 Dec 2019 at 18:35:46 -0500, Celejar wrote: > > > On Mon, 9 Dec 2019 19:34:29 +0000 > > Brian <a...@cityscape.co.uk> wrote: > > > > > On Mon 09 Dec 2019 at 14:10:56 -0500, Celejar wrote: > > > > ... > > > > > > Although I almost always use it with its --secure option, since I > > > > don't try to memorize passwords, but instead record them (in a plain > > > > text file) - who can remember hundreds of passwords? > > > > > > Indeed. Memorising is part of the password problem. I've indicated a > > > possible solution that does not rely on the fallibility of memory in > > > another mail. > > > > > > Your plain text storage method would benefit immensley from using the > > > scrypt package. > > > > I understand that many recommend encrypting the password store, but I > > haven't yet done this. 'pass', recommended by Jonas in another message > > in this thread, uses gpg to do this, and your recommendation of scrypt, > > IIUC, would serve a similar goal. > > Except is does not bring with it all the baggage of full disk encryption > and gpg and does one thing very well. Baggage of FDE? I'm using it anyway, so there is literally zero additional baggage involved. There isn't really much baggage involved to begin with - it's not too difficult to set up, and it requires no maintenance once set up, beyond either backing up the LUKS header material (I don't bother with that) or having good backups of your data (which you need anyway). If you aren't using FDE, then you have to start worrying about every single piece of software that stores sensitive data on disk (or whose sensitive data may get cached somewhere on disk). It seems to me that just using FDE actually involves much less baggage than tracking down all such cases and integrating something like scrypt on a case by case basis. Celejar
