#+TITLE: Secrets Manager
#+DATE: 2019-10-20
* Intro
It seems like everyone eventually writes their own password
manager. This is my take on it.
+ Simple.
+ Reasonable chance of it still working in 20 years.
+ No dependency on fancy language du jour.
Secrets are stored in files. One file per secret. The file name is
used to identify the secret. Secrets are encrypted / decrypted using
[[https://humungus.tedunangst.com/r/reop][=reop(1)=]]. =reop(1)= is available in packages on OpenBSD and in homebrew
on macOS.
* Scripts
** encrypt
#+begin_src shell
  #!/bin/sh
  j="$@"
  reop -E -m - -x "$j"
#+end_src
** decrypt
#+begin_src shell
  #!/bin/sh
  echo $1
  reop -D -m - -x "$1"
#+end_src
** 2fa
As a bonus here is a script for two factor authentication.
[[https://www.nongnu.org/oath-toolkit/man-oathtool.html][=oathtool(1)=]] is available in packages on OpenBSD and homebrew as
=oath-toolkit=. Whether this is safe depends on your threat model.
#+begin_src shell
  #!/bin/sh
  /usr/local/bin/oathtool --totp --base32 `reop -D -m - -x "$1"`
#+end_src
* Epilogue
Storing secrets in files, one file per secret, lets us organise our
secrets in a file system hierarchy. This is a thing most people are
already familiar with. The file system hierarchy can be backuped and
tracked in a version control system.

When tracking the secrets in a version control system it is beneficial
to store one secret per file. One can track when the secret got
created and changed. This enables us to revert back to an old version.

When secrets are stored in one big encrypted container changes are
opaque to the version control system. Some change happened, but you
can't find out what changed. This might be a good thing.

A crypto container only tells you: here are some secrets. A secret per
file leaks meta information. If you get access to my secret storage
you can tell that I'm [[https://bsd.network/@florian][@florian@bsd.network]]. But you will not be able
to log in.