[HN Gopher] Simple Password Management with GPG
___________________________________________________________________
Simple Password Management with GPG
Author : todsacerdoti
Score : 18 points
Date : 2020-11-29 19:13 UTC (3 hours ago)
(HTM) web link (tylerlmz1.github.io)
(TXT) w3m dump (tylerlmz1.github.io)
| okennedy wrote:
| There's one advantage to this approach that, as far as I've seen,
| no other password manager has been able to replicate. Pass is
| _simple_. It is literally a few hundred lines of clear, easy to
| read bash shell script (yeah, that 's a phrase I never thought
| I'd hear myself saying, ever). It's simple because it's created
| by composing standard, simple off-the-shelf technologies (bash,
| gpg, git). Compared to more monolithic solutions, it's easy to
| compose those very same technologies in a different way. That, in
| turn, makes it easy to adapt to new settings, and super resilient
| to new use cases like different sync technologies.
|
| (and yes, I do appreciate that this is not a feature that
| everyone wants/needs)
| Triv888 wrote:
| last time I looked at it, it revealed too much information even
| if you didn't have the pass-phrase
| zwayhowder wrote:
| From the article: > I'm aware of pass and tried it before I came
| to this setup, but I want to put more info than just a password
| string in my files, so that's why pass doesn't fit my need.
|
| I keep a lot more than just the password string in my files. They
| are just plain text files after all. My largest secret was a full
| dump of my old Lastpass database as some imports failed due to
| naming issues.
|
| This looks like an interesting exercise but I think the pass
| ecosystem provides a more robust tool for day to day use; though
| neither option are useful for my non-technical family members
| (IMHO).
|
| (edited for clarity)
| mrmattyboy wrote:
| Yeh, I wonder if it's due to the fact that `pass generate` and
| `pass insert` commands, by default, create one-line files that
| gives this impression.
| karlding wrote:
| Well, this exact use case is mentioned on the pass website
| [0].
|
| _> One approach is to use the multi-line functionality of
| pass (--multiline or -m in insert), and store the password
| itself on the first line of the file, and the additional
| information on subsequent lines._
|
| The Android Password Store app [1] also handles this format,
| interpreting the first line as the password and displaying
| the subsequent lines as additional information.
|
| [0] https://www.passwordstore.org/
|
| [1] https://github.com/android-password-store/Android-
| Password-S...
| cipherboy wrote:
| I use my own wrapper over pass,
| https://github.com/cipherboy/p, to use the remaining space
| as a JSON blob and pretty-print it with jq.
| throwaway201103 wrote:
| The only thing that is required (if you want the clipboard
| integration to work correctly) is that the first line of the
| file is the password. You can have other info in the file. Many
| of mine have my "secret questions" and their random gibberish
| answers, for instance.
| sigio wrote:
| Pass will store arbitrary text, and various pass frontends
| (qtpass, and ansible's passwordstore lookup plugin) will also
| allow you to put in key-value fields, and query them.
| Rizzoli_88 wrote:
| And why not to use https://passwordlive.github.io/ instead?
| tzs wrote:
| That appears to be a password generator. Given a secret and a
| name, it generates a password. You memorize that one secret,
| and use that and a name associated with each site to generate a
| password for that site.
|
| This can seem like a good idea, right up until you run into a
| site that requires periodic password changes leading to "name"
| becoming "name2", "name3", ... over time, and you needing to
| remember which one is current.
|
| That one also requires you to select the password length.
| Unless you find it acceptable to limit all passwords to the
| minimum of the maximum lengths allowed at all the sites you
| use, you will also need to remember for each site how long the
| password is.
|
| Same goes for character class restrictions and requirements.
|
| Password generators can work reasonable well, but generally
| only if they are coupled with storage to remember where you are
| in password rotation, password length, and character set rules
| for each site.
| robobro wrote:
| I'll stick with keypass, thanks... not sure what this solution
| offers that others do better
| q0x wrote:
| I
| Avamander wrote:
| Why not simply use BitWarden?
| q0x wrote:
| I've been using gopass to store and share passwords with team
| members at work https://www.gopass.pw
|
| It's pretty much the same as pass, where each password is stored
| in a .gpg encrypted file, but written in go so it works with both
| Mac and Windows.
| tao_oat wrote:
| I'm a pretty big fan of plain text for many things, but in this
| case it seems significantly simpler to just use a more full-
| featured password manager. I'm not sure I really see the benefit
| of a system like this.
|
| This setup (as well as pass) has one security downside over other
| password managers like 1Password, BitWarden, etc.: they leak
| information through the filenames you use to organize your
| passwords. Depending on who you are and your threat model, it
| could be pretty bad if someone gets a hold of your password store
| that contains an (encrypted) file called `silk road` or whatever.
| gnufx wrote:
| Is pass-tomb not a decent solution to that? I've not considered
| it necessary in my threat model, so don't know.
| throwaway201103 wrote:
| That's a valid critique for some use cases, I guess. Doesn't
| really apply to my uses, but there are some ways around this
| including having the presumably few very sensitive accounts
| saved using alias names that only you know.
| bobbylarrybobby wrote:
| You could use (say) UUIDs as the filenames and maintain an
| encrypted table containing the mapping between human readable
| filenames and UUIDs.
___________________________________________________________________
(page generated 2020-11-29 23:00 UTC)