|SECRET-MANAGER(7)||Miscellaneous Information Manual||SECRET-MANAGER(7)|
encrypt secrets with a master password
This is my
secret-manager. There are many
others like it, but this one is mine. My
secret-manager is my best friend.
It seems like everyone eventually writes their own password manager. This is my take on it.
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.
#!/bin/sh j="$@" reop -E -m - -x "$j"
#!/bin/sh echo $1 reop -D -m - -x "$1"
As a bonus here is a script for two factor authentication.
available in packages and homebrew as
Whether this is safe depends on your threat model.
#!/bin/sh /usr/local/bin/oathtool --totp --base32 `reop -D -m - -x "$1"`
Storing secrets in files, one file per secret lets us organise our secrets in a file system hierarchy 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 @email@example.com. But you will not be able to log in.
|October 21, 2019||man|