[talk] passwd entropy and strength

[Edward Capriolo]

On Tue, Nov 7, 2017 at 4:36 AM, Sujit K M <kmsujit at gmail.com> wrote:

>
>
> On Nov 7, 2017 1:41 AM, "Jim B." <jpb at jimby.name> wrote:
>
> * Thomas Levine <_ at thomaslevine.com> [2017-11-06 11:22]:
> > I am very satisfied with my password management approach, and
> > I keep debating whether it is safe to share. On one hand,
> > I theoretically think that sharing it would not provide an adversary
> > with enough information to guess my passwords or otherwise bother me,
> > but I also wonder whether it would tell the adversary enough to study
> > the relevant approaches/software enough to come up with a vulnerability.
> > Does anyone have any commentary on my concern?
> >
>
> Like many valuable things, it depends on your risk model.
> Who is your adversary?  A 3LA?  Large well funded criminal
> enterprise?  A really good hacker?  Random scripty?
>
> For most folks, I suspect it is the latter.  On the other hand,
> it doesn't matter who it is - personally I want to keep my shit
> safe from *all* prying eyes.  It may not be great shit but it's
> *my* shit, and I want to keep it that way.
>
> You could of course, follow the web of trust model - share
> individually with those you trust and gain feedback to improve
> your defenses.
>
> That said, I'll share my approach.  Just don't hack me and steal
> all my shit :-)  I'm going to number all the elements below
> to allow for easy commentary.  I welcome all comments and
> suggestions on how to improve this setup.
>
>
> 1. My "password vault" is just a text file on my TrueOS laptop.
>
> 2. The file (in some directory)  is encrypted with gpg2(1) with a
>    strong password.  I do not keep a clear text version on hard
>    disk.
>
> 3. To edit the file, I create a memory disk, format it with newfs(8)
>    mount it, and lock down the mountpoint.
>
> 4. I copy the encrypted file to the memory disk, decrypt, edit,
>    save, and re-encrypt it all on the memory disk.  Lastly, I
>    use "rm -P" to "securely delete" the decrypted copy that
>    I edited.
>
> 5. The encrypted file is copied back to my hard disk.
>
> 6. The memory disk is unmounted and deleted.
>
> 7. The ASCII-armored file is then steganographically embedded
>    inside a JPEG file.  I use outguess(1) (by Niels Provos)
>    for the steganography operations.  This operation has a
>    completely different password.
>
> 8. The .JPG file is copied to a secure location online.
>
>
> Thus, I have a local ASCII armored encrypted file on my disk,
> and I have a copy of that file embedded inside a JPEG file
> on my disk, and also somewhere online.
>
>
> 9. If I just want to view the file, I open up a new terminal,
>    cat the encrypted file and pipe it to "gpg2 -d" which
>    outputs the clear text to the terminal window.  I
>    copy/paste whatever I need, and delete the terminal window
>    when done.  pinentry(1) is used for passing the password
>    to gpg2 in this step.
>
>
> That's it.
>
> Comments welcome!
> Jim B.
>
>
>
> _______________________________________________
> talk mailing list
> talk at lists.nycbug.org
> http://lists.nycbug.org/mailman/listinfo/talk
>
> Do open source developer's really need security. Not a joke. Look you have
> source's of all projects.
>
> _______________________________________________
> talk mailing list
> talk at lists.nycbug.org
> http://lists.nycbug.org/mailman/listinfo/talk
>


Fuse has a nice filesystem called https://github.com/vgough/encfs. I
previously used that to mount a directory with "secret stuff". It can do
some of the things in step 1-6.

There also used to be this command line utility 'thrash' which attempted to
"secure delete" by writing over the blocks a variety of times.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nycbug.org/pipermail/talk/attachments/20171107/5c64f116/attachment-0001.html>