[announce] Development of an age-based secret manager

Skip to first unread message

William Woodruff

May 20, 2020, 9:33:50 PM5/20/20
to age...@googlegroups.com
Hi all,

First of all, I wanted to extend a thank you to Filippo and Ben for designing
age, and to str4d for their work on the Rust implementation.

Both implementations have been a refreshing breeze to work with compared
to PGP/GPG :-).

I'm writing to this list to (semi-officially) announce development on a
secret manager that uses age as its backend[1], and to record community
interest in using (and potentially helping develop) said manager.

As of writing, kbs2 is in an alpha state -- it's functional on
macOS and Linux and works with both the `age` and `rage` CLIs as backends
(as well as the `age` Rust crate), but is missing several important features
(like key rotation).

As some short examples of what it can currently do (> indicates output):

Adding a new "login" record:

$ kbs2 new login twitter.com
> Username: foobar
> Password: [hidden]

Adding a new "environment" record:

$ kbs2 new environment google-maps-api
> Value: [hidden]

Accessing secrets:

$ kbs2 pass twitter.com
> hunter2

# send it to the clipboard instead
$ kbs2 pass -c twitter

$ kbs2 env -n google-maps-api

Dumping and removing secrets:
$ kbs2 dump --json twitter.com
> {"timestamp":1589587069,"label":"twitter.com","kind":"Login","fields":[{"name":"username","value":"foobar"},{"name":"password","value":"hunter2"}]}

$ kbs2 rm twitter.com

I'm happy to answer any and all questions, but to preempt a few:

Q: Why another password manager?
A: I don't have a really good reason here, other than NIH and nervous energy.

Q: Why is it called kbs2?
A: It's a working name, based on an earlier (Keybase-based) secret manager[2]
that I developed. It borrows some opinions from its predecessor, but is
mainly named similarly because my muscle memory involves typing "kbs<tab>".
It should probably be renamed.

Thoughts are appreciated (including "stop it! not another manager!").


[1]: https://github.com/woodruffw/kbs2
[2]: https://github.com/kbsecret/kbsecret

Brian Williams

May 21, 2020, 12:24:26 AM5/21/20
to William Woodruff, age...@googlegroups.com
This is interesting, but I don’t see a whole lot of value in having a password vault with the keys sitting right next to it on the file system. IMO: it needs to be encrypted with a memorized secret or else you’re just adding extra steps for little gain. At that point you’d be re-inventing existing vaults though.

Cool project, but I don’t see myself using it.

> On May 20, 2020, at 8:33 PM, William Woodruff <wil...@yossarian.net> wrote:
> Hi all,
> --
> You received this message because you are subscribed to the Google Groups "age-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to age-dev+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/age-dev/20200521013337.sdwzu5b34xubvyba%40janus.

William Woodruff

May 21, 2020, 12:21:20 PM5/21/20
to Brian Williams, age...@googlegroups.com
Thanks for the feedback!

An optional password for encrypting records is something I intend to
add support for, to
bring `kbs2` to *roughly* the same set of security properties/threat
model as `pass` when
used with a password-protected PGP key.

Similarly for storage of the identity/private key itself: it sounds
like there's been some work
on storing/accessing age identities via PIV on Yubikeys, so having an
adaptor for that
would be a natural feature.
Reply all
Reply to author
0 new messages