[HN Gopher] Clever uses of pass, the Unix password manager
___________________________________________________________________
Clever uses of pass, the Unix password manager
Author : smartmic
Score : 227 points
Date : 2021-12-16 11:48 UTC (11 hours ago)
(HTM) web link (vitalyparnas.com)
(TXT) w3m dump (vitalyparnas.com)
| crawl_soever wrote:
| I use pass along with passff and my yubikey for gpg decryption of
| the password store and gpg-ssh syncing from my home git pass db.
| Works great
| TheCraiggers wrote:
| passff and other tools like them scare me too much. That
| browser extension has too much power. All it would take is the
| author to sell it to some bad actors (or turn into one) and a
| lot of people will be having a very bad day.
|
| Pasting my password into a form isn't _that_ bad, and it feels
| far safer.
| danuker wrote:
| You can disable automatic updates for the extension, download
| it manually, and inspect the XPI file before installing it.
|
| Instead of clicking "Add to Firefox", you can right-click and
| "Save Link As..."
| OJFord wrote:
| I use a couple of little scripts to do something somewhere in
| the middle that I'm happy with:
|
| `fzf-dmenu` spawns an alacritty window running fzf over given
| input.
|
| `pass-dmenu` calls the former with available password names;
| takes the result (if any) and decrypts & types it with `pass
| show $result | xdotool type --file -`.
| OJFord wrote:
| (And if it's not obvious, that's bound to a keypress, so
| from the browser I just hit F4, type e.g. 'hn<CR>' and my
| password is entered into the focussed input area.)
| hestefisk wrote:
| Looks very neat; nice Unix'y solution. Would love this to
| integrate with Bitwarden which I use on my phone.
| ossusermivami wrote:
| there is a pass import pluging allowing you to import bitwardn
| csv
|
| https://github.com/roddhjav/pass-import
|
| maybe you can "bridge it" with bitwarden-cli via some
| export/import commands or may as well use bitwarden-cli
| directly (but i find the pass ui much bettwer than bw cli
| command)
| zikduruqe wrote:
| Are you referring to Pass? There is...
| https://mssun.github.io/passforios/
|
| Works wonderfully and with OTPauth also.
|
| Run a bare git repo on your own network and there is no reason
| to use Bitwarden.
|
| Edit - and for those that are in AWS, you can use pass along
| with aws-vault to keep your ~/.aws creds in check.
| https://github.com/99designs/aws-vault
| watchdogtimer wrote:
| Is there an equivalent for Android?
| zikduruqe wrote:
| https://github.com/zeapo/Android-Password-Store#readme
| sigio wrote:
| passwordstore, in f-droid:
| https://f-droid.org/en/packages/dev.msfjarvis.aps/
| teddyc wrote:
| The article doesn't mention how well `pass` integrates with
| `git`. Once you do that, you get revision history, you can push
| it to a private repo (github, gitlap, etc), and keep your
| passwords in sync across multiple devices
| zaik wrote:
| On Android the app which supports pass+git is called 'Password
| Store' and can be found on F-Droid:
| https://f-droid.org/packages/dev.msfjarvis.aps
| kenmacd wrote:
| All great, but I wish `pass` was usable in scripts without having
| to pipe it through `head -n 1 | tr -d '\d'`
| vinceguidry wrote:
| One thing I love to use pass with is direnv. The problem direnv
| solves for me is: how can I have persistent local config/settings
| in a shared repo without having to push code? Invariably at work
| there is always the 'shared access credentials to third-party
| services'. Usually you just throw these in a .env file. This
| leaves them on your drive in plaintext.
|
| Instead, stuff the creds into pass, and since dotenv leverages
| bash, you can put substitutions in your .envrc file. Bonus, now
| that the creds are in a personal secured repo, you don't have to
| go hunting for the creds every time you want to spin up a new dev
| machine. (you do unfortunately still have to migrate your .envrc,
| I tried writing git tooling to make it easier but I could never
| find a convenient place to store them. I have ideas to extend git
| to try out the next time I want to iterate on this)
|
| This does require your app to be properly configurable with
| environment variables, meaning if an envvar is present, it should
| override all other settings. Envvars don't get set by accident so
| they should be treated as the ultimate settings. This is usually
| the case with most frameworks but I've run into Node apps where
| this wasn't the case. Maddening.
| mauli wrote:
| For the curl command though written like it won't show up in
| history, this will still show up in process parameters
|
| To fix this as well pass it into curl as a config via eg: curl
| [...] -K- <<< "--header auth:$(pass mysecret)"
| vesinisa wrote:
| curl -H/--header itself also takes a file name prefixed by @,
| including - for stdin. So you could go curl -H@- <<<'API-Key:
| Foobar', or if you need to specify multiple sensitive headers,
| curl -H@<(echo API-Key: Foo) -H@<(echo Pre-Shared: Bar)
| remram wrote:
| <() is a bash extension and won't work in another `sh` like
| dash.
| hvdijk wrote:
| And this matters a lot because history is normally only
| accessible to the current user (and root), but process command
| line arguments are normally accessible to all users.
| throwawayboise wrote:
| I've long thought that was a general problem. Why should I
| see the command line arguments from other users' processes?
|
| What if non-root could see their own processes in detail, but
| only the program name for other users' processes?
|
| Would that break a lot of other things?
| MayeulC wrote:
| Just try to change it by yourself:
| https://www.cyberciti.biz/faq/linux-hide-processes-from-
| othe...
|
| sudo mount -o remount,hidepid=1 /proc
| zokier wrote:
| > What if non-root could see their own processes in detail,
| but only the program name for other users' processes?
|
| At which point you might as well ask why do you need to see
| other users processes at all? And indeed, that is an option
| in grsec. I don't think it causes any major breakage, but
| there are probably some xkcd #1172 sort of things that
| break.
|
| edit: apparently there is nowdays also options in mainline
| for that too: https://pipo.blog/articles/20130930-hidepid-
| process-hiding and also possibly with selinux?
| mauli wrote:
| Hi, great question. Have not seen it being enabled break
| anything so far (only some cross user invouse written
| process monitoring scripts). Linux has a flag for this for
| the /proc mountpoint: hidepid=2
| [deleted]
| stevekemp wrote:
| Take a look at the `hidepid` option which is available to
| the /proc filesystem these days:
|
| https://www.cyberciti.biz/faq/linux-hide-processes-from-
| othe...
|
| Biggest surprise is that people can't run top/ps to see
| where load is coming from, but that aside I never noticed
| any particular downsides.
| yrro wrote:
| You can do this by mounting procfs with the hidepid=
| option. But it breaks systemd when enabled system-wide:
| https://github.com/systemd/systemd/issues/12955
|
| Individual units can opt-in to this behaviour with the
| ProtectProc= option though. But I don't think there's
| currently a good way to apply it to users' interactive
| processes.
| mehdix wrote:
| Most other users nowadays are likely to be your webserver,
| your application process, your database, your crawler, and
| a myriad of other long-running processes.
| ohazi wrote:
| Another useful thing to store as `pass` secrets is credit card
| numbers / parameters.
|
| This makes it easy to fill in card info online using the same
| password tools you're already using (passmenu, rofipass, etc.),
| without needing to go find your wallet, or rely on your browser's
| form auto-fill database (and worry about hidden fields attempting
| to exfiltrate that auto-fill data).
|
| I'm tempted to use `pass` to store TOTP seeds as well, but this
| seems like a bad idea because you'd be putting both factors in
| one place. Maybe a separate pass db stored offline or
| something...
| user3939382 wrote:
| FYI for those interested in CLI password management, there is a
| pretty good CLI for LastPass called lpass that even supports your
| Yubikeys.
|
| https://github.com/lastpass/lastpass-cli
| RMPR wrote:
| That's quite ... Clever. Now I can version my mbsyncrc and even
| my shell history without worrying about secrets leak.
| chrisweekly wrote:
| Be sure to protect those secrets though -- see eg peer comments
| about process params (made shortly after yours)
| tyingq wrote:
| Regular gpg does have a --passphrase-fd argument that's nice
| for this sort of thing. Where you can specify which file
| descriptor the passphrase/password is coming from. Very handy
| for integrating with scripts.
| tempodox wrote:
| Previous discussion:
| https://news.ycombinator.com/item?id=14819136
| matoro wrote:
| I also use this for OTP tokens instead of my phone!
|
| https://github.com/tadfisher/pass-otp
| twp wrote:
| With chezmoi you can use pass to store secrets in your dotfiles,
| for example if you want to set a secret API token in your
| ~/.bashrc you can use: export SECRET_API_TOKEN={{
| pass "api/token" | quote }}
|
| For more info see
| https://github.com/twpayne/chezmoi/blob/master/docs/HOWTO.md...
| and https://github.com/twpayne/chezmoi/blob/master/README.md.
| ryanianian wrote:
| What is the `quote` command that example pipes to? Seems handy
| but unsurprisingly hard to search for.
| twp wrote:
| In this example, `quote` is a function from sprig [1] which
| chemzoi uses with Go's text/template language [2].
|
| [1] https://masterminds.github.io/sprig/strings.html [2]
| https://pkg.go.dev/text/template
| iudqnolq wrote:
| I think it's this? I found it by googling "shell quote
| command".
|
| https://askubuntu.com/questions/354915/quote-command-in-
| the-...
| virchau13 wrote:
| Also note that `printf "%q"` is an alternative to this.
| cycomanic wrote:
| You could also use secret-tool for this, which is compatible
| with many tools that support the secret tool, I use keepassxc
| for example.
| waynesonfire wrote:
| incredible tool, works so well with yubikeys and cross platform.
| use it and recommend it all the time.
| simonmales wrote:
| Recently used pass to share passwords between colleagues (3 in
| total). Files are encrypted against three different GPG public
| keys and shared via Git.
|
| Works well enough for us.
| [deleted]
| zaik wrote:
| For teams there is also gopass
| (https://github.com/gopasspw/gopass) which is compatible with
| pass I believe.
| tata71 wrote:
| Hardware U2F to unlock would make this my dream.
| kitotik wrote:
| I use YubiKeys setup for gpg with pass, so unlocking the
| keyring requires both a yubikey and a PIN, but I haven't
| figured out how to do the U2F part.
| stevelosh wrote:
| If your goal is to force a touch to decrypt passwords,
| https://www.palkeo.com/en/blog/perfect-password-manager.html
| works. You can keep the GPG private key on a Yubikey and
| require a touch to decrypt.
| INTPenis wrote:
| Might as well link this blog[1] that helped me recently when I
| created a new GPG key for my yubikey and wanted to re-encrypt
| all my passwords for two keys.
|
| 1. https://medium.com/@davidpiegza/using-pass-in-a-
| team-1aa7adf...
| Ciantic wrote:
| Using single file for single password entry is very good idea.
| It's far better than any tools that opens the whole password
| database at once (KeePass, LastPass, Bitwarden etc).
|
| Reason is that you can use e.g. YubiKey to unlock individual
| entries _on touch_ , this means that you can't lose whole
| password database on ransomware attack, (unless the ransomware
| has been there for a very long time).
|
| Filippo Valsorda wrote about this: https://blog.filippo.io/touch-
| to-operate-password-store-yubi...
| hiptobecubic wrote:
| If you entire encrypted life is stored on a single computer
| with no backups you really should not be worried about
| ransomware and start worrying about things that will actually
| happen, like having your laptop stolen, or accidentally
| deleting something, or needing to replace your storage device.
| invokestatic wrote:
| This is still susceptible to ransomware. Ransomware will simply
| encrypt over each file with its own key, regardless of if the
| file is already encrypted or not.
| Ciantic wrote:
| Backups is of course required. I was talking about Ransomware
| which also enters your password database and steals the
| passwords in order to do more harm.
|
| With YubiKey you can make the GPG private key on offline
| machine and upload it to YubiKey. This way you can always
| have a offline backup of your private key, and thus you can
| backup your password database too.
| invokestatic wrote:
| The term "ransomware" is never used to describe malware
| that steals passwords, thats the point of confusion.
| Xylakant wrote:
| It also has a few downsides: Adding a new key requires re-
| encrypting every entry. Touching your yubikey hundreds of times
| gets old, fast.
| jehteh wrote:
| If you are using GPG keys and have the master key backed up
| somewhere you can fairly easily use that on an offline
| machine to add the new key to the full batch of password
| files without needing to perform a million button presses.
| captn3m0 wrote:
| Yup. My backup key (the one that doesn't travel with me)
| doesn't have the touch policy and I use that for any bulk
| operations.
| doubled112 wrote:
| Been there and done that. People are backing up those keys,
| right?
|
| Could also disable the touch to decrypt feature while you
| performed the rekey?
| kenmacd wrote:
| You probably shouldn't be able to disable touch. If you
| can disable it then malware can disable it.
|
| I'd highly recommend using the `fix` option instead of
| `on` to make sure it can't be disabled.
| jehteh wrote:
| I hope people back up their GPG keys (and test their
| backups! My subkeys on the yubikey expire annually,
| forcing me to validate my master key backup at least once
| a year).
|
| Disabling touch is another option if you need to do a
| large batch of operations and are comfortable that your
| machine is secure.
| taeric wrote:
| I'm not sure I follow. Adding a secret is done with your
| public key, so no need to even touch the yubikey to do that.
| And the idea is each one is a separate file. So, adding does
| not impact any other file.
|
| Edit: oh. Adding a new key, not password. I see how I
| misread.
| INTPenis wrote:
| Touching? What? I did this recently and it's very simple
| thanks to pass init. I now have two keys, my old one and my
| new one that is on my yubikey.
| kenmacd wrote:
| Did you have our key on a yubikey and that yubikey set to
| require a touch for every operation?
| INTPenis wrote:
| No I wasn't even aware of this feature.
|
| I just enter my pin once and it works until I pull it
| out.
| kenmacd wrote:
| Here's a script that will set that mode, in case you'd
| like to use it. It prevents someone/malware from being
| able to use your key after you've unlocked it. For
| example if you hacked my computer and tried to use it to
| ssh to another machine you'd be unable because you'd need
| me to tap the key.
|
| I'd suggest trying 'on' before 'fix', but then switching
| to 'fix' for the extra security it provides.
|
| https://github.com/a-dma/yubitouch
| mongol wrote:
| I think use of the copy buffer is the weakness of pass. Can't it
| be read by any process?
| INTPenis wrote:
| This is a very good point about infosec that a lot of password
| manager users overlook. Me included.
|
| In wayland you can pipe the password into wl-copy -o so it will
| only be pasted once then disappear.
|
| In Xorg you'd need a callback after running pass that runs
| xclip -i /dev/null some time after the password is copied.
|
| There is no good solution to this in Linux that does not
| involve discipline.
| tyingq wrote:
| The clipboard? How well it's protected varies by distro, X11 vs
| Wayland, etc.
| captn3m0 wrote:
| Docker supports a credential-helper module[0], which supports 4
| different backends for fetching the docker registry credentials:
| osxkeychain, pass, wincred, and secretservice.
|
| pass lets you use GPG-smartcards, and many of those (such as
| Yubikeys) will let you enforce touch-policies for
| signing/encruption.
|
| As a combination of both these however, I must touch my Yubikey
| every time I pull a new docker image.
|
| Another cool use-case is that I use the terraform-pass-provider
| to save secrets for my personal terraform project.
|
| [0]: https://github.com/docker/docker-credential-helpers
| mike-cardwell wrote:
| In my ansible.cfg I have: vault_password_file =
| tools/vault.sh
|
| In my tools/vault.sh I have: echo -n $(pass
| infrastructure/ansible-vault)
|
| This lets me store my ansible vault master password for managing
| my personal infrastructure inside pass. I like it.
| VTimofeenko wrote:
| Ansible also has a collection that allows to work with pass's
| password store directly[1]. Have been using it with a dedicated
| pass repo for a while now, the PASSWORD_STORE_DIR variable can
| be loaded through direnv when entering directory with ansible
| playbooks to separate infrastructure credentials from user
| ones.
|
| [1]:
| https://docs.ansible.com/ansible/latest/collections/communit...
| MayeulC wrote:
| Is there a way to use it with the D-Bus org.freedesktop.secrets
| service?
| woile wrote:
| I wrote a cheatsheet[0] for gopass, which I've been using with
| different teams and personal with great success. It's the same as
| pass but with support for multiple stores.
|
| I'd like to see something similar but with age support .
|
| [0]: https://woile.github.io/gopass-cheat-sheet/
| edoceo wrote:
| Would love to see more examples of how to use this across teams -
| any pointers?
| chpatrick wrote:
| I wouldn't recommend it unless you like GPG key management.
| (re)encrypting passwords for all your team members is a real
| pain. We recently switched from pass to BitWarden and it's been
| far more convenient.
| janikvonrotz wrote:
| https://janikvonrotz.ch/2018/04/03/using-pass-in-teams/
| parasew wrote:
| Check out sicuit, also GPG based.
| https://codeberg.org/simonrepp/sicuit
| syx wrote:
| been using pass for more than 3 years now never had an issue,
| great CLI tool
| tialaramex wrote:
| I still really like how it makes random passwords given a
| permitted character set. It uses tr -cd to read only matching
| character bytes - discarding any others - from the random
| device. If you instead try to be less wasteful in turning
| random bytes into characters from the chosen set, you are in a
| sticky situation very quickly where your passwords might be
| less random than they should be, whereas bytes from the random
| device are cheap, so just throw away all the ones that aren't
| suitable and get more. So simple and yet I'm sure it wouldn't
| have occurred to me.
| wizzwizz4 wrote:
| It means password generation takes variable time; this:
|
| * opens you up to timing attacks on your PRNG (unlikely to be
| a problem in real life, but you never know)
|
| * might run forever
| assbuttbuttass wrote:
| It has probability 0 of running forever
| wizzwizz4 wrote:
| Assuming a perfect RNG, but PRNGs don't have infinite
| state. So it's either impossible, or has a finite
| probability, with a finite probability for each of those
| cases, for an overall finite (non-zero) subjective
| probability of it running forever (in ideal program-
| space; obviously it will never run forever in real life).
| tialaramex wrote:
| No, you don't need a perfect RNG. You need anything
| that's not _completely horrible_.
|
| Remember, we're not trying to read a whole _password_
| from the device, just one matching byte at a time. So,
| even if our password character set is a single character
| (pass will let you do that, but obviously you should not
| use such passwords in real life) we 're talking about
| statistically 1 out of 256 bytes matches or else our PRNG
| is useless.
|
| You correctly observe that the PRNG has finite state, but
| its state isn't so tiny that it only emits a handful of
| the 256 possible bytes before getting back to where it
| started, nobody would use such a busted algorithm.
|
| RC4 is considered broken and unusable because the
| keystream is biased and thus distinguishable from random
| - to the extent that if you read a few _million_ bytes
| from it you can detect the bias, but you 're asking us to
| imagine that the random device has a PRNG _many orders of
| magnitude worse_ in order for this to have any effect at
| all.
| wizzwizz4 wrote:
| > _You correctly observe that the PRNG has finite state,
| but its state isn 't so tiny that it only emits a handful
| of the 256 possible bytes before getting back to where it
| started, nobody would use such a busted algorithm._
|
| If the PRNG always loops through all possible states,
| then sure. But if there's a possibility, however small,
| of it getting stuck in a small loop, very rarely?
| konschubert wrote:
| But a nonzero possibility of running longer than x for
| any x>0
|
| ;)
|
| In practice, it doesn't matter, I agree.
| shakna wrote:
| A successful timing attack against /dev/urandom would be a
| major bug that you could expect to be highly prioritised by
| the Linux team.
|
| That is, for most people it is well outside the attack
| surface that they need to care about.
| [deleted]
| jhgb wrote:
| If you have an M-sized alphabet and you need an n-character
| password, why not just take [?]log2 Mn[?] bits and interpret
| it as a number in base M? That seems even simpler to me.
| assbuttbuttass wrote:
| This is "simpler" because it's a one line shell snippet:
| tr -dc "0-z" < /dev/urandom | head -c10
| tialaramex wrote:
| Let's try it.
|
| For example I should like a 1-character password, from the
| alphabet of A, B and C.
|
| So that's 2 bits. We read two bits (awkward, the random
| device is of course byte oriented). Now, we have a 2-bit
| value and we're trying to pick A, B or C. But what do we do
| with the 4th possibility from our 2-bit value?
|
| We could decide too bad we'll treat it as A (or B, or C)
| anyway, but now we've introduced a non-random bias to our
| supposedly random password.
|
| The _non-horrible option_ is to throw away this possibility
| and read two more bits hoping for a different outcome. The
| exact same algorithm pass uses, except you 've added the
| extra complexity of reading less than one byte at a time
| from the device...
| jhgb wrote:
| With a non-trivial (= much more realistic) length of your
| random number, how do you ever lose more than a fraction
| of a bit of entropy this way? Let's say you want a
| 16-character alphanumeric (a-zA-Z0-9) password. log2
| 6216[?]95.267. Let's say you pull 96 bits and ignore the
| imbalance. Then you have
| 2x6216-296=16116640899382729306982711296 options with a
| probability of 2x2-96 and 296-6216 options with a
| probability of just 2-96. That comes out as around 95.203
| bits of entropy, which isn't significantly different from
| 95.267. What obvious fault am I missing here?
| tialaramex wrote:
| > What obvious fault am I missing here?
|
| Well, let's begin with the fact it's worse. You argue
| it's not "much" worse, but it is clearly _worse_ not the
| same. Under 'pass' all passwords conforming to chosen
| rules are equally likely, under your approach some are
| twice as likely as others.
|
| But then the other characteristic is simplicity. Using
| 'tr -cd' is, by my counting, five characters. How big is
| your best implementation of this supposedly "even
| simpler" but worse solution?
| jhgb wrote:
| > Under 'pass' all passwords conforming to chosen rules
| are equally likely, under your approach some are twice as
| likely as others.
|
| But they're passwords. At most half of the passwords will
| have different probability than the rest which means that
| you're still left with a staggering number of un-brute-
| forceable passwords. Two to the power of ninety nine is
| practically indistinguishable from two to the power of
| one hundred.
|
| By the way, if you're still obsessed about completely
| equal probabilities here, you can just drop the whole
| sequence of bits if it's larger than the number of
| alternatives when interpreted as a binary number and
| fetch a new one. It seems to me that the expected value
| of number of bits consumed for such a process won't
| exceed twice the number of bits that are technically
| necessary (because the probabilities of individual
| numbers of attempts are a geometric sequence with a
| factor of at most 0.5 summing to exactly 1, which would
| have an expected value of 2), which is around 12.5 bits
| per character. With a filtration like tr -dc "0-z"
| mentioned below you'll consume roughly 27.3 bits per
| character on average. So "better" is a subjective term
| here; one solution may be simpler to write in a shell
| command line, another consumes much less entropy. If
| you're deciding what to do, you need to weigh your
| criteria properly if you have more of them. You may very
| well have different criteria than I do; that happens.
|
| > Using 'tr -cd' is, by my counting, five characters
|
| I probably wouldn't use this in the first place because
| it requires a subprocess and a binary that I might not
| have on some computers. So by my counting this could be
| hundreds of kilobytes of extra code. Division with a
| remainder is most likely something you already have in
| your standard library regardless of whether you use it or
| not.
| ufo wrote:
| I don't understant what you mean here. Why would the
| passwords be less random?
| gspr wrote:
| Yeah. I think it might be the tool that's given me the most
| quality of life per line of code :-)
|
| Stellar. Absolutely stellar piece of software. Always does
| exactly what I want it to, never gets in my way ever!
| choiway wrote:
| I got stuck at init
| cjauvin wrote:
| I use pass with Emacs, using this package [1], and it's very
| nicely integrated and useful.
|
| [1] https://melpa.org/#/pass
| encryptluks2 wrote:
| Thank you..
|
| Just setup isync yesterday. So close to having freedom to move
| from Google whenever I want
| loudmax wrote:
| `pass` was written by Jason Donenfeld, the developer who gave us
| WireGuard.
|
| It's is a bash script that makes it convenient and easy to use
| gpg2, the OpenPGP encryption tool. Frankly, I'm kind of shocked
| at how difficult it is to use the gpg2 command line utility.
| Clearly it's an extremely powerful tool, but it's written with
| the assumption that the user has a very deep understanding of how
| encryption and key signing work. To use `pass` effectively you
| should have a basic understanding of encryption, but unlike gpg2
| you don't need to dedicate a week to grok the manpage.
| plafl wrote:
| I don't know why, but I usually find the usability of anything
| crypto-related terrible like ssh or managing certificates.
| Granted I have no idea about security but I would say that I
| have some knowledge of computers, I use 2FA minimum everywhere,
| I use VPN almost daily, I ssh into machines frequently, I use a
| password manager, I update my software and I'm picky about what
| I install. You get the idea. And yet I dread having
| authentication problems, my only resort googling to see what
| other poor souls managed to do. I think some part of it is part
| of the nature of the problem since you have to assume some of
| your users are malicious but a good part is just not caring,
| like if you don't know what the problem is you should not even
| be close to a computer.
| jamal-kumar wrote:
| As much as I love Jason Donenfeld's work, I tried to use pass
| and the gpg requirement just rubbed me the wrong way. It's
| basically just gpg-encrpyting a text file and unlocking that
| along with some wrappers for basic password manager
| functionality (I guess most important is clipboard
| functionality and clearing it automatically after some
| seconds), but somehow that seems like a weak point to me. It's
| a whole lot of reliance on one extremely bloated suite of
| applications when I feel like something standalone and about as
| compact would be better somehow.
| yepguy wrote:
| A few pass-related projects are working on an age[1] backend
| in addition to gpg. I think gopass already has support for
| it.
|
| [1]: https://age-encryption.org/
| tex0 wrote:
| Correct. Gopass has very early age support. It fully works
| but the UX is not great (yet).
| pqb wrote:
| Oh dammit. I have stopped using Gopass and rewrote pass
| just for that reason - missing AGE encryption. At least I
| have learned something new and I feel I have better UI -
| fuzzy finder instead of their TUI. However, big kudos to
| Gopass team for awesome work and really useful tool.
|
| Before I start working on next project... Do you
| recognize any mobile app, which could replace
| PasswordStore app for Android [0] but with AGE support?
|
| [0]: https://github.com/android-password-store/Android-
| Password-S...
| cobby wrote:
| > missing AGE encryption
|
| I am just curious. What makes AGE backend better than GPG
| one?
| yepguy wrote:
| Age is much simpler to use in nearly every way, whether
| that's interactively (keys are just files!), in
| scripting, or in implementation.
|
| I'm still sticking to gpg for the foreseeable future, but
| between age and sequoia[1] I'm hopeful that things will
| soon be much easier to use.
|
| [1]: https://sequoia-pgp.org/
| yepguy wrote:
| Android Password Store itself is keen to add age
| support[1], but I don't know of anything usable right
| now. You could probably use gopass in termux in the mean
| time.
|
| [1]: https://github.com/android-password-store/Android-
| Password-S...
| zikduruqe wrote:
| Here's one I have been playing with success.
|
| https://github.com/chrisswanda/passage
| HotHotLava wrote:
| As a user, I also often feel like `gpg` brings a lot of
| annoying accidental complexity to `pass`, (like the need to
| "ultimately trust" keys before they become usable) but on the
| other hand it enables integration with hardware tokens like
| Yubikeys and in extension mobile devices (via openkeychain)
| that as far as I know wouldn't be possible with a more modern
| age-based backend.
| beagle3 wrote:
| SSH has included file encryption for a few versions now,
| and iirc supports yubikeys -- probably would be more useful
| a backend than age.
| tialaramex wrote:
| > SSH has included file encryption for a few versions now
|
| Mmm. I don't think so. Recent OpenSSH includes file
| _signatures_ not encryption.
| upofadown wrote:
| >like the need to "ultimately trust" keys before they
| become usable
|
| Did you have to do that manually at one time? All the
| keypairs that I make start out that way when created.
|
| When creating a keypair for pass all you have to do is
| generate the key using defaults while remembering a bit of
| the user ID to give to pass.
| GekkePrutser wrote:
| Yep the integration with Yubikey is amazing. Both on mobile
| and desktop <3
| yepguy wrote:
| https://github.com/str4d/age-plugin-yubikey
| vngzs wrote:
| Besides that, pass leaks metadata.
|
| If your passwords are the only part of your password manager
| you think are secret, then you're probably not considering
| the utility of an enumeration of all your network handles.
| Mine aren't very interesting, but I wouldn't post that on
| GitHub, even in a private repo.
|
| I love pass and use it. But when I need to carry my password
| database around, I don't rely on pass alone - I throw the
| pass database in a Veracrypt container. That way if my flash
| drive is stolen, it's just an encrypted blob.
| rank0 wrote:
| I get what you're saying but it's just different philosophies
| no?
|
| Seems like pass wants to use the Unix philosophy of "do one
| thing well" so it relies on gpg for encryption instead of
| rolling its own.
| rkeene2 wrote:
| I wrote a tool called hunter2 [0][1] which is very similar but
| uses PKCS#11 modules, which may be more common than GPG since
| the entire US Government uses them.
|
| [0] https://chiselapp.com/user/rkeene/repository/hunter2/ [1]
| https://github.com/rkeene/hunter2 (mirror)
| SpaceManNabs wrote:
| How do you know my password?
| Overtonwindow wrote:
| I found it on a sticky note beneath your mouse pad ;-)
| laumars wrote:
| Just in case anyone doesn't know the reference:
|
| http://bash.org/?244321
| aidenn0 wrote:
| I don't, I just copy and pasted the stars. you see
| "hunter2" but I see "****"
| SpaceManNabs wrote:
| thats neat, I didnt know HN did that
| hnlmorg wrote:
| Love the name. That alone is genius, never mind all the work
| you've put into the tool itself.
| waynesonfire wrote:
| i'd love to see the genius. what makes it so clever?
| rectang wrote:
| I wish someone would mint a user-friendly GPG wrapper for
| signing releases and quorum-based publishing. Dealing with raw
| GPG to sign releases is doable but a pain. And we need quorum
| publishing to guard against supply-chain attacks.
|
| But simple and user-friendly UX design is hard. As a user of
| `pass`, I'm grateful for what I have.
| assbuttbuttass wrote:
| I'm shocked no one mentioned passmenu, a secret script that comes
| with pass located in usr/share/doc/pass/examples/dmenu/passmenu
|
| Bind this script to a keybinding, and it will load all your
| passwords into dmenu and let you type the first few characters of
| a website name, then copy the password to the clipboard. No CLI
| needed.
| sam_lowry_ wrote:
| Second that. passmenu is very useful, although most of the time
| I use Chromium or FF plugins for that.
|
| Also, Password Store by Harsh Shandilya on Android is a
| wonderful little tool. Too pity is has only two sponsors on
| Github.
| INTPenis wrote:
| It's actually a separate package on Fedora called passmenu.
| Maybe because dmenu is not standard for Fedora users by
| default.
| ahnick wrote:
| For those interested in pass for use in shell script based
| contexts, you may also find encpass.sh
| (https://github.com/plyint/encpass.sh) useful. This is a simple
| tool I wrote (a while ago now) to encrypt/decrypt secrets and
| store them in a manner very similar to pass, except it uses
| OpenSSL instead of GPG. Since it is also just a shell script and
| it's only real dependency is OpenSSL, then it can be used in a
| wide array of environments where installing additional software
| may not be an option. It also has hooks in the code to write your
| own extensions, which can be used to add features or utilize an
| entirely different backend instead of OpenSSL. Check out the
| Keybase extension as an example.
| (https://github.com/plyint/encpass.sh/blob/master/extensions/...)
| sam_lowry_ wrote:
| The stdout from `pass` is awful, even for copy-pasting. OTOH,
| gopass [1], an otherwise 100% compatible drop-in replacement
| does the job much better and has some neat collaborative
| features as well.
|
| [1] https://github.com/gopasspw/gopass
| kenmacd wrote:
| Wow, I just tried it and found `gopass show -o ___` works
| perfectly to scripts that want just the password without any
| null bytes or newlines in it. You've converted me. Thank you
| for mentioning it, I never thought to look for a compatible
| drop-in.
___________________________________________________________________
(page generated 2021-12-16 23:01 UTC)