Secrets Manager

Intro
Scripts
- encrypt
- decrypt
- 2fa
Epilogue

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 reop(1). reop(1) is available in packages on OpenBSD and in homebrew on macOS.

Scripts

encrypt

  #!/bin/sh
  j="$@"
  reop -E -m - -x "$j"

decrypt

  #!/bin/sh
  echo $1
  reop -D -m - -x "$1"

2fa

As a bonus here is a script for two factor authentication. oathtool(1) is available in packages on OpenBSD and homebrew as oath-toolkit. Whether this is safe depends on your threat model.

  #!/bin/sh
  /usr/local/bin/oathtool --totp --base32 `reop -D -m - -x "$1"`

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 @florian@bsd.network. But you will not be able to log in.

1.9 KiB Raw Blame History