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

131–140 of 154 posts

Re: Clever uses of pass, the Unix password manager

#131

Post by kenmacd »

INTPenis wrote: post #125
kenmacd wrote: post #119

Earlier quoted context omitted.

Did you have our key on a yubikey and that yubikey set to require a touch for every operation?

No I wasn't even aware of this feature. I just enter my pin once and it works until I pull it out.

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

Re: Clever uses of pass, the Unix password manager

#133

Post by GauntletWizard »

At a previous job, I set up all our Kubernetes secrets such that their canonical location was in pass; Creating or updating them was a simple shell script:

    kubectl create secret generic -o yaml --dry-run \
        --from-literal "foo=$(pass show foo)" 
        foo | kubectl apply -f -
I was very pleased with it - It was simple enough for developers to use where necessary, easy to distribute passwords, and worked very well.

The next guy ripped it out and replaced with Vault and none of the passwords have been rotated since.

Re: Clever uses of pass, the Unix password manager

#134

Post by rrauenza »

waynesonfire wrote: post #129
hnlmorg wrote: post #60

Earlier quoted context omitted.

Love the name. That alone is genius, never mind all the work you've put into the tool itself.

i'd love to see the genius. what makes it so clever?

Mentioned farther in the thread, but it's based on this: http://bash.org/?244321

Re: Clever uses of pass, the Unix password manager

#135

Post by tialaramex »

rectang wrote: post #79
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.

For the signing problem, both signify (and its clones) and modern OpenSSH (ssh-keygen -Y) do what you want today without all the baggage of OpenPGP, obviously that would mean explicitly choosing to migrate off OpenPGP signatures, but that does not seem unreasonable.

Re: Clever uses of pass, the Unix password manager

#136

Post by loulouxiv »

upofadown wrote: post #126
HotHotLava wrote: post #71

Earlier quoted context omitted.

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.

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

I had to do it when importing keys on another device

Re: Clever uses of pass, the Unix password manager

#137

Post by marcosdumay »

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

The timing depends on your charset. You may not want to tell it to everyone on the street, but it's not something you need to keep secret either.

Re: Clever uses of pass, the Unix password manager

#138

Post by [deleted] »

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…

[deleted]

Re: Clever uses of pass, the Unix password manager

#139

Post by HotHotLava »

upofadown wrote: post #126
HotHotLava wrote: post #71

Earlier quoted context omitted.

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.

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

Yes, every time I want to set it up on a new device I have to import and trust all public keys that it should encode to; and if that device gets its own gpg key then that key also has to be distributed to and trusted at all prior sites. Which isn't very often, but still somewhat regularly (ie. new laptop, new yubikey, formatted hard drive, etc.)

I think it would be a great addition if pass could actually automate this by storing all relevant public keys internally.

Re: Clever uses of pass, the Unix password manager

#140

Post by tialaramex »

jhgb wrote: post #124
tialaramex wrote: post #116

Earlier quoted context omitted.

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

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

> another consumes much less entropy

To the extent that it could mean something to "consume" entropy from the random device they're both outputting the same size of password and so they're consuming roughly the same amount of entropy. Assuming the random device works as intended this would be a distinction that makes no difference anyway.

> a binary that I might not have on some computers

A binary that's included in the Linux Standard Base. Which computers don't you have it on?

> this could be hundreds of kilobytes of extra code

More like a few dozen kilobytes, although of course on tiny Linux systems it's bundled into something like busybox so much less.

> Division with a remainder is most likely something you already have in your standard library regardless of whether you use it or not.

The shell, which is what pass is written for, does have division with a remainder, but it cannot do this operation on 96-bit integers. So now you've added another constraint "rewrite this software in a language which has 96-bit integers, or more if longer passwords are allowed" [Hint: Longer passwords are very much allowed in pass]

So far what you've achieved is to show that this is trickier than you thought, yet produces worse results. Again, this is why I like what Jason did here.

Post reply on HN