
Show HN: A password manager using Keybase for encryption and storage - woodruffw
https://github.com/woodruffw/kbsecret
======
Shank
Everything about Keybase FS is experimental, I guess. This password manager
says:

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

~~~
woodruffw
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).

~~~
indytechcook
My team has been using KBFS for the past year to share keys and secrets
without any issues.

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

~~~
shakna
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).

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

~~~
Bluestrike2
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...](https://vi.stackexchange.com/questions/6177/the-simplest-way-to-start-
vim-in-private-mode?lq=1)

------
chias
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 "foo@example.com"
        Please enter the password: barbazquux

~~~
woodruffw
You'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.

    
    
        $ kbsecret new login gmail -i
        Username? *****
        Password? *********
    

(The asterisks don't actually show up, since tty echo is disabled for
interactive input. This needs to be tweaked so that it's only disabled for
sensitive inputs, but I haven't gotten around to that yet.)

[1]: [https://yossarian.net/docs/kbsecret-man/kbsecret-
new.1.html](https://yossarian.net/docs/kbsecret-man/kbsecret-new.1.html)

~~~
minitech
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`.)

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

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

------
eridius
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?

~~~
woodruffw
> 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 ;)

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

~~~
woodruffw
> 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!

------
rrggrr
Why not simply use PASS with your Keybase gpg key?

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

~~~
rrggrr
Makes sense. Do we know if KBFS is deemed cryptographically secure? I haven't
kept up on it.

~~~
woodruffw
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](https://keybase.io/docs/crypto/overview)

[2]: [https://github.com/keybase/kbfs](https://github.com/keybase/kbfs)

[3]: [https://github.com/keybase/client](https://github.com/keybase/client)

------
Diti
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. :(

------
smoyer
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/](https://www.passwordstore.org/).

~~~
woodruffw
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/.

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

~~~
woodruffw
Ah, I had no idea you could use multiple keys in pass. That's what I get for
using it so briefly.

------
45h34jh53k4j
Great idea! i will follow the evolution of this product

~~~
woodruffw
Thank you!

------
daddykotex
You mind find inspiration from
[http://passwordstore.org](http://passwordstore.org)

