Show HN: A password manager using Keybase for encryption and storage(github.com)
github.com
Show HN: A password manager using Keybase for encryption and storage
https://github.com/woodruffw/kbsecret
9 comments
I put that in there because I'm just one person, working on this in my spare time. I don't think there are any immediate vulnerabilities in KBSecret itself - that's more of a warning that I'll probably be breaking things as I work towards a stable release.
As for KBFS, I can only relay my experience. So far, it's been completely reliable for me - no crashes, hangups, or lost data on what I assume is a lower-priority target for them (Linux).
As for KBFS, I can only relay my experience. So far, it's been completely reliable for me - no crashes, hangups, or lost data on what I assume is a lower-priority target for them (Linux).
My team has been using KBFS for the past year to share keys and secrets without any issues.
Have you just been dumping them in a directory, or have you come up with a system for organizing and accessing them?
Most of my work on KBSecret so far has been aimed at my own use cases (single user, multiple machine), so I'd love to hear your perspective on KBFS's strengths and weaknesses in your own setup.
Most of my work on KBSecret so far has been aimed at my own use cases (single user, multiple machine), so I'd love to hear your perspective on KBFS's strengths and weaknesses in your own setup.
Also using KBFS for some sharing between work groups.
The biggest headache is "groups" -> At the moment, a folder is linked to a specific set of users, which is great, but adding and removing users basically requires recreating and resharing the folder from scratch. (We scripted it easy enough, but its not something the KeyBase UI does).
The biggest headache is "groups" -> At the moment, a folder is linked to a specific set of users, which is great, but adding and removing users basically requires recreating and resharing the folder from scratch. (We scripted it easy enough, but its not something the KeyBase UI does).
A couple of thoughts on security:
How I understand this, when the /keybase VFS is mounted, all the files are accessible in clear from the user's point of view. It means that file traversal attacks (eg: browser) could potentially access these files without having the user's computer fully compromised.
Another issue is that most text editors aren't designed to handle sensitive data and thus tend to copy (eg: undo) buffers to various locations on the disk. It's quite probably that when editing the files, a copy is created somewhere else in the user's home which might not be encrypted.
How I understand this, when the /keybase VFS is mounted, all the files are accessible in clear from the user's point of view. It means that file traversal attacks (eg: browser) could potentially access these files without having the user's computer fully compromised.
Another issue is that most text editors aren't designed to handle sensitive data and thus tend to copy (eg: undo) buffers to various locations on the disk. It's quite probably that when editing the files, a copy is created somewhere else in the user's home which might not be encrypted.
Setting aside the question of directory traversal, you can configure your text editor to be a bit more private. With vim, you can use autocommands for dealing with encrypted files, those in a certain directory (such as /keybase), etc.[0] In general though, whole disk encryption should deal with random copies, swap files, and the like.
0. https://vi.stackexchange.com/questions/6177/the-simplest-way...
0. https://vi.stackexchange.com/questions/6177/the-simplest-way...
Unless I'm missing something, this looks like it ends up sprinkling all of your passwords into your .bash_history file. Maybe saving a credential should be a prompted action:
$ kbsecret new login gmail "[email protected]"
Please enter the password: barbazquuxYou're not missing something; I documented that under "Security Considerations" for `kbsecret login` [1].
`kbsecret login` provides the `-i` and `--interactive` flags for exactly this purpose. They should probably be the default, but the reasoning for the current form was making scripting easy.
[1]: https://yossarian.net/docs/kbsecret-man/kbsecret-new.1.html
`kbsecret login` provides the `-i` and `--interactive` flags for exactly this purpose. They should probably be the default, but the reasoning for the current form was making scripting easy.
$ kbsecret new login gmail -i
Username? *****
Password? *********
[1]: https://yossarian.net/docs/kbsecret-man/kbsecret-new.1.html
That’s unsafe even for scripts; unprivileged processes can, by default, read the argv of any other process. (Try `sudo -u nobody cat /proc/$(pgrep -n kbsecret)/cmdline`.)
Hmm. My first reaction is that this isn't a huge issue, since each `kbsecret` invocation runs for a fraction of a second. However, that's unreasonable of me.
Do you know of any workaround for this? If it's unavoidable without requiring the user to change `/proc/`, then I'll probably have to get rid of argv input altogether.
Do you know of any workaround for this? If it's unavoidable without requiring the user to change `/proc/`, then I'll probably have to get rid of argv input altogether.
There might be a workaround, but I think the common practice is to just avoid the problem with environment variables or by reading values from stdin.
You could use $stdout.isatty as an indicator if it is a shell or interactive and make the default for each?
That sounds like a good solution, thanks!
Edit: I've created 0.4.1 for this change:
`kbsecret login` now performs interactive input by default, provided that `$stdin.tty?` is true and the -a/--args flag is not passed.
That provides both a more reasonable default and a way to override the safer behavior when testing for a TTY isn't a good enough indicator of noninteractivity.
Edit: I've created 0.4.1 for this change:
`kbsecret login` now performs interactive input by default, provided that `$stdin.tty?` is true and the -a/--args flag is not passed.
That provides both a more reasonable default and a way to override the safer behavior when testing for a TTY isn't a good enough indicator of noninteractivity.
Prefixing your shell command with a space will prevent it from ending up in history.
Say whaaaaaaaaaat
$ echo $HISTCONTROL
ignoreboth
HISTCONTROL
A colon-separated list of values controlling how commands are saved on the history list. If the list of values includes ignorespace, lines which begin with a space character are not saved in the history list. A value of ignoredups causes lines matching the previous history entry to not be saved.
Bash - the gift that keeps giving :-) TIL!
This is very good work. Though, KBFS makes it impossible for me to use it in the non-privileged (non-root) environments I work on. :(
This is effectively what I'm already doing - I use pass for Linux and save my folder hierarchy to KBFS. It has the added advantage of already have browser plugins and a desktop GUI tool available for it - https://www.passwordstore.org/.
Well, this has a few advantages beyond just a folder hierarchy:
* KBSecret's records are structured, meaning that they have "type" information and can be filtered by use (logins, environment keys, code snippets, &c). I've seen a few attempts (and made one of my own) to add structured records to pass(1), but it ends up being pretty hacky and unreliable.
* One of my goals was to make it easy to share passwords and other secrets with other people, especially once you have a group of people who you know consistently need access to the same secrets. I'm not familiar with an easy way to do that with pass(1), but KBFS makes it at easy as sharing files (i.e., KBSecret records) between /keybase/private/user1,user2,user3/.
* KBSecret's records are structured, meaning that they have "type" information and can be filtered by use (logins, environment keys, code snippets, &c). I've seen a few attempts (and made one of my own) to add structured records to pass(1), but it ends up being pretty hacky and unreliable.
* One of my goals was to make it easy to share passwords and other secrets with other people, especially once you have a group of people who you know consistently need access to the same secrets. I'm not familiar with an easy way to do that with pass(1), but KBFS makes it at easy as sharing files (i.e., KBSecret records) between /keybase/private/user1,user2,user3/.
Agreed ... I've been tuning my pass "records" and still haven't got them exactly the way I want. Sharing pass records is possible since you can encrypt each password with more than one public key.
Ah, I had no idea you could use multiple keys in pass. That's what I get for using it so briefly.
You mind find inspiration from http://passwordstore.org
Why not simply use PASS with your Keybase gpg key?
Well, I wanted something with structured records. `pass` can sort of do that, but it's not built into it.
I also wanted to take advantage of KBFS to do the encryption transparently and expose records as individual files. KBSecret just provides a structure; you can use plain old shell scripts (and I/O primitives) to access your records once they're in place.
It's more of an experiment than anything else currently, but those are the two big motivating ideas.
I also wanted to take advantage of KBFS to do the encryption transparently and expose records as individual files. KBSecret just provides a structure; you can use plain old shell scripts (and I/O primitives) to access your records once they're in place.
It's more of an experiment than anything else currently, but those are the two big motivating ideas.
Makes sense. Do we know if KBFS is deemed cryptographically secure? I haven't kept up on it.
I don't know if there's been a formal audit, but they've published an overview of their cryptographic methods and practices [1].
They've also open-sourced KBFS itself and the `keybase` client [2][3], but again, not sure on the audit.
[1]: https://keybase.io/docs/crypto/overview
[2]: https://github.com/keybase/kbfs
[3]: https://github.com/keybase/client
They've also open-sourced KBFS itself and the `keybase` client [2][3], but again, not sure on the audit.
[1]: https://keybase.io/docs/crypto/overview
[2]: https://github.com/keybase/kbfs
[3]: https://github.com/keybase/client
I started using pass last week after a post on HN, loving it so far.
Could I have a link to that post please?
it's an old one https://news.ycombinator.com/item?id=12890498
Or even just use Pass as normal, setting the password store directory to a path in your KBFS vfs. Two layers of encryption + standard Pass usage. :D
How do you specify the pass file directory?
The original pass program allows overriding the default directory with the PASSWORD_STORE_DIR environment variable. I use gopass [0] though which supports directly configuring this via cli/config file.
[0]: https://github.com/justwatchcom/gopass
[0]: https://github.com/justwatchcom/gopass
Interesting, but how does this handle adding/removing members from a team? And I assume every single member of the team has to independently set up the session?
> Interesting, but how does this handle adding/removing members from a team?
Not at the moment, but this wouldn't be too difficult. Records are shared under the /keybase/private/user1,user2,user3/kbsecret hierarchy, so adding or removing a user would just be a matter of changing the user list (moving the directory) and updating the session to match.
> And I assume every single member of the team has to independently set up the session?
Nope! This is a huge benefit of KBFS - the session is shared with all members immediately.
Edit: Oh, I see what you mean by "set up the session." The session files are shared with all members immediately, but each member needs to tell their own copy of `kbsecret` to load that session.
Now that KBSecret uses its own hierarchy, there are ways to fix that. I just hadn't thought of it before ;)
Not at the moment, but this wouldn't be too difficult. Records are shared under the /keybase/private/user1,user2,user3/kbsecret hierarchy, so adding or removing a user would just be a matter of changing the user list (moving the directory) and updating the session to match.
> And I assume every single member of the team has to independently set up the session?
Nope! This is a huge benefit of KBFS - the session is shared with all members immediately.
Edit: Oh, I see what you mean by "set up the session." The session files are shared with all members immediately, but each member needs to tell their own copy of `kbsecret` to load that session.
Now that KBSecret uses its own hierarchy, there are ways to fix that. I just hadn't thought of it before ;)
Thanks for making `kbsecret` and having it based on KBFS!
> Records are shared under the /keybase/private/user1,user2,user3/kbsecret hierarchy, so adding or removing a user would just be a matter of changing the user list (moving the directory) and updating the session to match.
I wanted to mention that we are actually actively working on a feature called, not surprisingly, teams. It'll be useful for both chat and KBFS. A team has builtin mechanism for adding/removing members, and has its own sigchain.
This should provide applications like `kbsecret` with smoother support for team. So for KBFS for example, instead of `/keybase/private/alice,bob`, you'll have `/keybase/team/foo` which has Alice and Bob as members. When Celia joins the team `foo`, you can keep the same path `/keybase/team/foo` rather than having to move stuff (which is actually a copy-then-delete since it'd require re-encryption) to a new folder `/keybase/private/alice,bob,celia`. We'll also have a slightly different rekey process that makes this super fast.
> Records are shared under the /keybase/private/user1,user2,user3/kbsecret hierarchy, so adding or removing a user would just be a matter of changing the user list (moving the directory) and updating the session to match.
I wanted to mention that we are actually actively working on a feature called, not surprisingly, teams. It'll be useful for both chat and KBFS. A team has builtin mechanism for adding/removing members, and has its own sigchain.
This should provide applications like `kbsecret` with smoother support for team. So for KBFS for example, instead of `/keybase/private/alice,bob`, you'll have `/keybase/team/foo` which has Alice and Bob as members. When Celia joins the team `foo`, you can keep the same path `/keybase/team/foo` rather than having to move stuff (which is actually a copy-then-delete since it'd require re-encryption) to a new folder `/keybase/private/alice,bob,celia`. We'll also have a slightly different rekey process that makes this super fast.
> I wanted to mention that we are actually actively working on a feature called, not surprisingly, teams. It'll be useful for both chat and KBFS. A team has builtin mechanism for adding/removing members, and has its own sigchain.
Fantastic! That would be a tremendous boon.
> Thanks for making `kbsecret` and having it based on KBFS!
Thanks for making Keybase and KBFS; they're some of my favorite daily-use applications!
Fantastic! That would be a tremendous boon.
> Thanks for making `kbsecret` and having it based on KBFS!
Thanks for making Keybase and KBFS; they're some of my favorite daily-use applications!
> Note: This is still a work in process. Use it with caution.
Meanwhile, Keybase FS says:
> At the time of this document, there are very few people using this system. We're just getting started testing. Note that we could, hypothetically, lose your data at any time. Or push a bug that makes you throw away your private keys. Ugh, burn.
I don't know if everyone is just overly cautious when it comes to declaring crypto stuff stable, but stability is a requirement of products like this for me. I wish these tools were audited more.