Security
Overview
This document describes the security mechanisms in place and how they are expected to reduce risks.
Secrets
Secrets are expected to be passed as environment variables or configuration files as a base64 encoded string. The decoded payload will be passed to the encryption algorithm.
It's highly recommended to generate new secrets using the following OpenSSL command:
openssl rand -base64 32
Secrets rotation
There currently is no built-in facility to allow secrets to be rotated seamlessly. This may come in the future, but it's a low priority, since the GCM-SIV mode resolves the nonce duplication security issues.
Storage at-rest
All PII is encrypted before storage inside PostgreSQL. The encryption algorithm uses AES-GCM-SIV with keys of 256 bits. This algorithm has been chosen because it provides both ciphertext authentication and nonce reuse resistance.
Symmetric encryption algorithm upgrade
PII is stored encrypted at-rest using a "versioned encryption scheme" this allows us to "upgrade" the encryption algorithm in a one-way direction for a different (stronger) algorithm when the time comes.
The versioned encryption scheme works this way:
- it's backward compatible with all previously chosen algorithms when decrypting secrets.
- it will always re-encrypt secrets with the newest encryption algorithm supported.
Note: the encryption password is expected to always be the same.
Row Level Security (RLS)
RLS rules are enabled on the TOTP table. Every user is identified as the tenant for its own TOTP. This makes it impossible to share TOTPs between different users, but it's not in the scope of this project anyway.
Vulnerabilities
Even though this is a small project, security is taken seriously.
If you discover a vulnerability, please do not open a public issue: doing so could expose other users to risk before a fix is available. Instead, report it privately by reaching out directly (e.g. via a private message or email). Your report will be acknowledged and addressed as promptly as possible.