Show HN: Passbox – Another password manager using Bash and GPG(github.com)
github.com
Show HN: Passbox – Another password manager using Bash and GPG
https://github.com/RobBollons/passbox
4 comments
Downside of pass is that the filenames are in the open. Thus, metadata (which sites you have account on) is not secured. Linked one seems to store everything in a single encrypted file.
Upside is that it has ton of implementations readily available - browser integration, mobile apps, etc. Linked one (passbox) is just a bash script at the moment, if one wants to use it across multiple devices and platforms, the experience may be quite rough.
Another upside is that with a single file model you have to invent your own conflict resolution scheme. For pass, git just does the trick. And this one doesn't seem to have anything in this regard.
Upside is that it has ton of implementations readily available - browser integration, mobile apps, etc. Linked one (passbox) is just a bash script at the moment, if one wants to use it across multiple devices and platforms, the experience may be quite rough.
Another upside is that with a single file model you have to invent your own conflict resolution scheme. For pass, git just does the trick. And this one doesn't seem to have anything in this regard.
> Downside of pass is that the filenames are in the open.
The "entry" names (which I think would correspond to filenames in `pass`) appear to be passed on the command line here; they'll likely get swept up in your shell's history file, unless you're careful. (And thus, are essentially in the open, just like pass.) That said, I think most shells make their histfiles 600, so they're not directly readable. (And I think `pass`'s directory is 700, similarly.) And you have to trust the machine you're running on, of course; otherwise, I can just dump the memory as soon as your keyring is decrypted.
I think it was when `pass` was on HN that I mentioned this; I have a terminal keyring manager myself[1], but one of the design decisions I made in it (aside from a single-file archive) was to not pass entry names on the command line, specifically so they won't get swept up in histfiles. It's easy, though, it make it optional, and let the user decide what they want to do. Of course, your
[1] which is way not ready to be looked at… also seems like we as a crowd enjoy this topic (keyrings) as a side project.
The "entry" names (which I think would correspond to filenames in `pass`) appear to be passed on the command line here; they'll likely get swept up in your shell's history file, unless you're careful. (And thus, are essentially in the open, just like pass.) That said, I think most shells make their histfiles 600, so they're not directly readable. (And I think `pass`'s directory is 700, similarly.) And you have to trust the machine you're running on, of course; otherwise, I can just dump the memory as soon as your keyring is decrypted.
I think it was when `pass` was on HN that I mentioned this; I have a terminal keyring manager myself[1], but one of the design decisions I made in it (aside from a single-file archive) was to not pass entry names on the command line, specifically so they won't get swept up in histfiles. It's easy, though, it make it optional, and let the user decide what they want to do. Of course, your
[1] which is way not ready to be looked at… also seems like we as a crowd enjoy this topic (keyrings) as a side project.
There is HISTIGNORE for a reason ;)
But, yeah, if one forgot to add pass there, the metadata will be leaked.
But, yeah, if one forgot to add pass there, the metadata will be leaked.
I did not know about HISTIGNORE! Very interesting. I knew about HISTCONTROL=ignorespace, though I did not know it was a variable; I just thought that was a hard-coded feature.
...filenames are in the open.
Is this something that can't be fixed by directory perms?
Is this something that can't be fixed by directory perms?
If you trust the box.
That said, if you have a secure trusted machine with FDE that you don't let strangers touch, and where every piece of software is well-isolated (for example, web browser is sandboxed and can't access the ~/.password-store/), then yeah, filesystem permissions will do the trick.
But, for example, if you sync using git repo hosted on some third-party VPS then directory permissions won't protect you from that host owner or whoever gains superuser access to the filesystem.
(Hey, don't downvote the parent, he didn't said anything wrong, just asked a question! In my opinion that contributes to the discussion.)
That said, if you have a secure trusted machine with FDE that you don't let strangers touch, and where every piece of software is well-isolated (for example, web browser is sandboxed and can't access the ~/.password-store/), then yeah, filesystem permissions will do the trick.
But, for example, if you sync using git repo hosted on some third-party VPS then directory permissions won't protect you from that host owner or whoever gains superuser access to the filesystem.
(Hey, don't downvote the parent, he didn't said anything wrong, just asked a question! In my opinion that contributes to the discussion.)
I agree. Perhaps a zip file with a password?
the standard unix password manager
Annoying amount of hubris.
This pile of unattractive bash-snippets is neither unix nor standard. Just call it what it is: A very dependent script that will probably work on most GNU/Linux distributions.
Annoying amount of hubris.
This pile of unattractive bash-snippets is neither unix nor standard. Just call it what it is: A very dependent script that will probably work on most GNU/Linux distributions.
Good shout, I've added it to the 'Similar Projects' section of the readme.
I had a play with 'pass' before but i wasn't keen on the way it splits the entries up into separate files which was one of the drivers for putting passbox together.
I had a play with 'pass' before but i wasn't keen on the way it splits the entries up into separate files which was one of the drivers for putting passbox together.
Is there a way to share passwords with passbox? pass lets you encrypt different files with different keys so it could potentially be used within an organization with varying levels of permission. Another advantage is that each password is just an encrypted file that could be read with just GPG if pass isn't installed.
Not really, i wanted this to just be a personal password manager and sharing passwords is mostly out of scope in that respect. Although there's nothing stopping you having multiple 'passbox.gpg' files of different names with different keys by manipulating the PASSBOX_LOCATION env variable within aliases or something like that.
You can still decrypt the file with just GPG if you wanted and modify the file in plain text. Passbox just acts as a layer on top of that to interrogate the encrypted GPG file.
You can still decrypt the file with just GPG if you wanted and modify the file in plain text. Passbox just acts as a layer on top of that to interrogate the encrypted GPG file.
I've been using pass since mitro.co announced their shutdown.
The only (somewhat big) downside to this, and related unix pw managers is the sheer lack of browser compatibility - mobile would also be nice, as that's one of the places where it's a PITA to use and enter long passphrases.
pass claims to have both, but doesn't:
https://github.com/jvenant/passff#readme does not work.
The iOS app has disappeared from github: https://github.com/rephorm/pass-ios#readme
It's solvable problems, I just find it a somewhat important part of a password manager.
The only (somewhat big) downside to this, and related unix pw managers is the sheer lack of browser compatibility - mobile would also be nice, as that's one of the places where it's a PITA to use and enter long passphrases.
pass claims to have both, but doesn't:
https://github.com/jvenant/passff#readme does not work.
The iOS app has disappeared from github: https://github.com/rephorm/pass-ios#readme
It's solvable problems, I just find it a somewhat important part of a password manager.
I'm running a small agency with two friends and we're keeping mitro alive (and better: are fixing issues) here: https://passopolis.com/
Firefox and Chrome extensions are working, and I'm currently spending a few hours a week on migrating to the new Firefox-extension protocol.
Firefox and Chrome extensions are working, and I'm currently spending a few hours a week on migrating to the new Firefox-extension protocol.
I suppose it just depends what you look for in a password manager. I tried lots of solutions from Last Pass, KeepassX to pass but i prefer the scriptability and portability of a command line based password manager and i'm not overly bothered about mobile and browser.
You're right, and don't take this as a challenge, I'm honestly wondering:
How come you aren't bothered? I ask because I can't image apart from:
a. I use short or cryptically unsafe passphrases,
b. I use passphrases and type them easily,
c. I only need to log in a few times.
Am I forgetting others?
How come you aren't bothered? I ask because I can't image apart from:
a. I use short or cryptically unsafe passphrases,
b. I use passphrases and type them easily,
c. I only need to log in a few times.
Am I forgetting others?
For non-mobile use-cases the passmenu script distributed with pass comes in handy:
http://git.zx2c4.com/password-store/tree/contrib/dmenu/passm...
It types the selected password via xdotool.
http://git.zx2c4.com/password-store/tree/contrib/dmenu/passm...
It types the selected password via xdotool.
How do you work with these terminal-based password managers? Request the password (à la `passbox get facebook`) and then copy 'n' paste it into the website?
Are there any security concerns of the password being in the clipboard/memory (beyond the obvious of accidentally pasting it)?
Are there any security concerns of the password being in the clipboard/memory (beyond the obvious of accidentally pasting it)?
That's definitely a way of using it, another is to just manually type it in as you see it and clear the terminal buffer afterwards. If you do use your clipboard it does require a certain amount of due diligence in making sure you empty it afterwards if you're concerned about that as a security risk. It would be easy enough to create a simple script that could copy it to your clipboard and then clear the clipboard after a time delay.
It would be possible to construct an attack using Flash to access a users clipboard form a web browser.
I know a lot of people like to have browser plugins for password managers but i always feel uncomfortable using them because i don't understand enough about the technology to trust that it wont be vulnerable.
It would be possible to construct an attack using Flash to access a users clipboard form a web browser.
I know a lot of people like to have browser plugins for password managers but i always feel uncomfortable using them because i don't understand enough about the technology to trust that it wont be vulnerable.
It would be easy enough to create a simple script that could copy it to
your clipboard and then clear the clipboard after a time delay.
pass [0] (see comment above [1]) claims to do that:
[1] https://news.ycombinator.com/item?id=10190719
pass [0] (see comment above [1]) claims to do that:
show [ --clip, -c ] pass-name
Decrypt and print a password named pass-name. If --clip or -c is specified,
do not print the password but instead copy the first line to the clipboard
using xclip(1) and then restore the clip‐board after 45 (or
PASSWORD_STORE_CLIP_TIME) seconds.
[1] https://news.ycombinator.com/item?id=10190719
Clipboard integration probably isn't something i would look to add to passbox myself, but if someone can find a way to get it to work nicely cross platform and submit a PR then i would likely merge it.
This looks very nice, but I would need browser extensions and mobile apps to go along with it.
1Password is honestly the one app that has kept me from switching to Linux from OSX. Would love to see a decent open source alternative.
1Password is honestly the one app that has kept me from switching to Linux from OSX. Would love to see a decent open source alternative.
Has anyone build a hash style password manager.
hash(website name + global password + increment) = password to use?
or something like it
hash(website name + global password + increment) = password to use?
or something like it
Seems like everyone build this scheme. Seriously, there are many browser plugins and websites implementing it, and almost all of them ignore research (I'm guilty too). Also, most of them use fast hash functions instead of proper password hashes.
Here's a quick analysis of pros and cons of password generators compared to password managers: http://crypto.stackexchange.com/a/5691/291
I used a password generator (my own) for a few years, and I'm happy to use a password manager now, which is safer and makes me avoid keeping certain information in my mind (e.g. if I already have an account on this website and what's my username for it).
Here's a quick analysis of pros and cons of password generators compared to password managers: http://crypto.stackexchange.com/a/5691/291
I used a password generator (my own) for a few years, and I'm happy to use a password manager now, which is safer and makes me avoid keeping certain information in my mind (e.g. if I already have an account on this website and what's my username for it).
That's a very popular scheme.
The major downside is that site saying "your password must [not] contain blah-blah-blah"/"be N to M characters long"/"may contain only digits" when the generated one just happens to not conform to such restriction. In my personal experience, one out of dozen sites tries to be smartass about the passwords, so the scheme is a PITA in the long run.
Without the increment you also can't rotate password, while with the increment you need to store the increment value (and if you do keep the notes and the master secret, why not just remember the password already?)
The password managers are more flexible than password generators, because they don't have such limitations.
The major downside is that site saying "your password must [not] contain blah-blah-blah"/"be N to M characters long"/"may contain only digits" when the generated one just happens to not conform to such restriction. In my personal experience, one out of dozen sites tries to be smartass about the passwords, so the scheme is a PITA in the long run.
Without the increment you also can't rotate password, while with the increment you need to store the increment value (and if you do keep the notes and the master secret, why not just remember the password already?)
The password managers are more flexible than password generators, because they don't have such limitations.
I wrote my own hashing method [1] that given a correct spec for password restrictions would always generate a valid password. It does it by taking the hash in base64, then translating those a new set of base64 characters chosen to increase the likelihood of getting a valid password. If one generated is not valid, it then iterates until a valid one is found (by cycling the bits).
I have used this personally since I wrote it. Given the downsides, I agree that password managers are probably better for most people.
[1]: https://github.com/onionjake/doh
I have used this personally since I wrote it. Given the downsides, I agree that password managers are probably better for most people.
[1]: https://github.com/onionjake/doh
This has similar security properties to a salted password based key derivation scheme. Given the output, and assuming a function with effective preimage resistance, the best way to find the global password is brute force it by trying lots of master passwords. The security is a function of the forward difficulty of the KDF (in space and time) and the quality of the master password. Use the password 'password' and MD5 and you don't have much security except through obscurity. Use an 8 word diceware password and scypt and you are doing great security wise (assuming of course no implementation problems, a big assumption!)
https://oneshallpass.com/ does that plus has a bunch of other options. It's by the founder of OkCupid and Keybase.io
I assume that the "increment" is so that you can hash the password again in case the password needs to be changed. But how do you tie the increment to that particular password? Otherwise your increment would have to be global, and if one of your passwords gets compromised you would have to hash all 200 others again simply in order to keep the increment consistent.
http://masterpasswordapp.com/ has a pretty good implementation.
I had people tell me that this would have problems with entropy. I didn't fully understand that, though.
pass - the standard unix password manager
http://www.passwordstore.org/