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.
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).
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.
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).
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.
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
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.)
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.
`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.
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.
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 ;)
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.
> 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!
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.
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.
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/.
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.
> 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.