Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clever uses of pass, the Unix password manager

vitalyparnas.com

Post reply on HN
Print view View original

71–80 of 154 posts

Re: Clever uses of pass, the Unix password manager

#71

Post by HotHotLava »

jamal-kumar wrote: post #45
loudmax wrote: post #15

`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…

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 re…

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.

Re: Clever uses of pass, the Unix password manager

#73

Post by rank0 »

jamal-kumar wrote: post #45
loudmax wrote: post #15

`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…

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 re…

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.

Re: Clever uses of pass, the Unix password manager

#74

Post by Ciantic »

invokestatic wrote: post #31
Ciantic wrote: post #12

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 ab…

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.

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.

Re: Clever uses of pass, the Unix password manager

#75

Post by tialaramex »

jhgb wrote: post #39
tialaramex wrote: post #17

Earlier quoted context omitted.

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 rando…

If you have an M-sized alphabet and you need an n-character password, why not just take ⌈log₂ Mⁿ⌉ bits and interpret it as a number in base M? That seems even simpler to me.

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...

Re: Clever uses of pass, the Unix password manager

#77

Post by tex0 »

yepguy wrote: post #57
jamal-kumar wrote: post #45

Earlier quoted context omitted.

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 re…

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/

Correct. Gopass has very early age support. It fully works but the UX is not great (yet).

Re: Clever uses of pass, the Unix password manager

#78

Post by virchau13 »

ryanianian wrote: post #58
twp wrote: post #52

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 .

What is the `quote` command that example pipes to? Seems handy but unsurprisingly hard to search for.

Also note that `printf "%q"` is an alternative to this.

Re: Clever uses of pass, the Unix password manager

#79

Post by rectang »

loudmax wrote: post #15

`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…

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.

Re: Clever uses of pass, the Unix password manager

#80

Post by shakna »

wizzwizz4 wrote: post #34
tialaramex wrote: post #17

Earlier quoted context omitted.

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 rando…

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

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.

Post reply on HN