Show HN: Passmgr – Securely store passphrases and retrieve them via commandline
godoc.org
godoc.org
Only downside that I've seen users mention is that filenames are readable.
Storing secrets in separate files could leak metadata, especially when using a public git repository for synchronization between devices.
Other than that, you dont have to deal with gpg key management in passmgr.
We both can make different choices and that's OK, but I'm happy to see as a design point that both of our password managers are interactive loops to avoid the history management of the shell. I will say, though, that my files routinely hold way more than 4 passwords and listing them all for the user to choose by number is not really appealing: so one of the biggest things that `tagaloop` does is that it just lets you grep through them at the interactive console. You might want to consider that as a very important feature.
However i like the idea of having a single binary with a minmal set of dependencies, which can be moved around easily wherever i want to use it.
It's Unix Philosophy at it's purest, and the reason why I use it for my password management.
But if you sync your secrets across devices, using services that are not under your control, or your device gets stolen, more information than necessary got leaked.
People have made various pass extensions, by the way, to work around this.
I would still prefer https://www.passwordstore.org/ though. I like the ability to insert a new passwd without having to type a passphrase. And it's more robust because updating 1 password only rewrites 1 file, whereas with passmgr the whole file is rewritten. This also mean the passwordstore data base is easier to revision-control and sync across multiple machines. Finally with passwordstore I can update my passphrase by simply changing it on my PGP key ("gpg --edit-key $id" and use the "passwd" command.) But with passmgr there is no mechanism to change it (every entry would have to be decrypted and re-encrypted.)
Also I think the 6 seconds for pasting the password before the clipboard is cleared is a bit too short, pass has 45 seconds which is a bit too much, maybe something between 15-30 seconds would be optimal, or better yet: Let the user configure it.
Here you go: https://github.com/mssun/passforios
The storage of arbitrary secrets is definitly on my todo list.
As for the git integration i do not see the point of having it. For someone who is able to set up a remote git repo, it should be trivial to use git for synchronization, even without "git integration", since everything is stored in a single file.
I have not yet looked into browser integration or clients for mobile platforms, but maybe there is a way to integrate with existing apps/extensions.
- You never ever lose anything. Updated the wrong password? No problem, just `git reset`
- Having everything in it's own file let's you merge changes made on different machines (I use this all the time, I'm not keeping every machine always up-to-date). If everything's in a single file, any change would result in a hard to resolve merge conflict.
- All the other git goodness, including file history (e.g. when was the last time I changed this password), mutliple users (e.g. a shared family store), and more
While some of these are debatable and git isn't really made for binary data, I still think it's a very good fit.
I've stole some links from https://github.com/gioele/pw to show that there are downsides to the separate files approach:
E: quick Google and some digging later I see the situation, thanks for alerting me to this though!
The clipboard lib you're using just spawns xclip (or xsel) on Unix. xclip has a -loops argument that is the maximum number of pastes. So you could just spawn:
xclip -loops 1 -in -selection clipboard
And the password would be available to paste exactly once. Unfortunately I don't think xsel has any such option.There are clipboard manager apps that could grab the paste immediately and persist it, but I'm not sure how common they are or if they are default anywhere.
I've already implemented some features based on your ideas:
- configurable timeouts: https://github.com/urld/passmgr/commit/069c209
- basic filter functionality: https://github.com/urld/passmgr/commit/3c4b1ed4
But i think the UI needs improvement, and core features like master passphrase updates are still missing. Also the clipboard handling could be improved (depending on the platform).
Im not sure yet, if and how browser integration or iOS/Android clients could or should work with passmgr, but if i have time i will think about it.
[1]https://github.com/jeremy21212121/bash-steganography-passwor...
It was just an exercise to get better with bash, but I actually use it. It could be trivially modified to take a password instead of gpg.
https://github.com/ojensen5115/pw/
It uses a file in your private Keybase directory as its datastore (so obviously depends on Keybase). As such, it eschews the need for its own master password (or more accurately, it depends on your previous authentication with your Keybase master password), and thus can operate in an individual-run basis.
It could still use a decent amount of work (e.g. option to save a credential based on a randomly generated password, etc), but I've been using it myself recently and like it quite a lot.
> https://github.com/ojensen5115/pw/
I made one as well. Same name, totally different philosophy. ;)
Shameless self pitch. It is a little slicker, not needing the master key to save sites.
I guess you could also argue that by using AES, passmgr has the advantage of being post-quantum secure, if that is important to you.