Memberium · Secret Vault
The database is the prize,
and the vault keeps it empty
On most sites, your CRM key, payment credentials, and members’ two-factor seeds sit in the database in plaintext, one backup away from walking out the door. The Secret Vault pulls the static ones out entirely and seals the rest under a key the database never holds.
The wall
The field would not save
You installed the plugin, connected your CRM, pasted your API key into the field, hit save, and moved on, or tried to. For one setting, the field displayed a sentence instead of accepting a value.
A plugin can take that key and tuck it into the database without a pause, leaving one more plaintext row in one more table, a ticking time bomb the site owner never agreed to arm. This field refused to do either.
This is the default state of most WordPress security, not a hypothetical one, and it is the state the Secret Vault was built to end.
If you are a developer, that sentence is an instruction. If you are not, and most membership site owners are not, it is a wall. You do not know which file wp-config.php is, and either lack SFTP credentials or have them and are afraid to use them. One misplaced character in that file takes the entire site offline with a white screen. So you close the tab, meaning to come back to it, and never do. And if you build sites for clients, the wall is a familiar hassle: waiting for them to send SFTP credentials, working around hosting setups you have never seen, or a host that does not offer file access at all.
And while that key stays undefined, every secret the system was supposed to protect sits in the database in plaintext. One backup in the wrong hands or one misconfigured shared host is enough for the secrets to walk out the door, with the encryption that was supposed to stop them never turned on.
The problem
Four costs behind one innocent sentence
None of this is the site owner’s fault. The status quo hands them a choice between security they cannot configure and convenience that leaves them exposed.
Editing wp-config.php by hand
Every secret, by convention, is a constant in wp-config.php. Editing it means SFTP, a text editor, and the knowledge that one stray semicolon whitescreens the site.
The database is the prize
Attackers seldom bother breaking encryption; they walk off with the database. A stolen backup, a leaked copy of your site, each hands over every plaintext credential at once.
The master-key paradox
Encrypt at rest and you need a key. Store it beside the data and you have locked the safe with its own combination; put it in wp-config.php and you are back to editing that file by hand.
Half-encrypted by default
Plugins that “encrypt” often seal only the obvious fields. The API key is protected, but the key that unlocks it sits in plaintext right next door, making the protection theatrical.
The shift
Secrets stop being mixed in with your content
Memberium doesn’t force you to make an uncomfortable choice. The static secrets leave the database entirely; the dynamic ones that must stay are sealed under a key the database does not hold. The prize is no longer where the attacker is looking for it.
- Secrets stored alongside your site’s content
- Moved out into the vault file
- Loaded into memory, ready the instant they’re needed
- Old copy deleted, the migration is a move rather than a copy
A database backup now returns your content, and none of the keys.
Zero-friction install
Security that turns itself on
The master key is the one secret everything else depends on, and historically the one step guaranteed not to happen. Memberium generates it and writes it into the vault at activation, before the owner ever sees a settings screen.
- Works as soon as the plugin is activated, no key to define, no step to remember
- Never loses your keys, reactivating the plugin leaves your vault exactly as it was
- Honors what is already there, an existing wp-config or environment definition always wins
Secrets stay out of your content
Your credentials are not part of your site’s stored content
A secret kept outside the database, loaded only into memory, has properties a stored value cannot match. The static credentials, the ones attackers want most, are not sitting in the site’s data to be stolen.
- Invisible to a backup, never stored with your site’s content
- Free to read, no lookup, no decryption, no delay on the request path
- Removed on the way in, the old stored copy is deleted in the same operation
- Survives on and off, re-enabling an integration does not mean re-entering its credentials
Encrypted at rest
For the secrets that must stay
OAuth tokens rotate. Two-factor seeds are written per member, thousands of them. These must stay in the database, but never in plaintext. For everything that stays, Memberium encrypts before it is written.
- Algorithm
- xchacha20poly1305 · authenticated encryption
- Tamper evidence
- one altered byte fails decryption, not corrupt data
- Key binding
- HKDF-derived per location · one context cannot open another
- Master key
- lives in the vault file, outside the database
- Cached decrypt
- brief in-memory window, then gone from disk
Locked-down hosting
No dead ends
Some hosting, shared plans, containerized deploys, locked-down production stacks, doesn’t let the site write to its own plugin folder. Memberium treats that as a first-class situation rather than an edge case.
- Adapts to what the host allows, “copy what you need” instead of “save”
- Hands you the exact lines to paste into your site’s config file
- Plays nice with your host, if your host already provides a key, that key wins
One vault, every secret
A shared file, a single guarantee
One vault holds them all. The CRM’s API key, the payment credentials, the email service’s token, the master encryption key itself, every secret across every connector and module lands in the same place, protected by one set of guarantees. New integrations mean one more secret in a file that already exists, managed alongside the rest.
The security story does not fragment as the site grows.
Why the combination matters
Friction down, protection up
Any one piece is useful. The combination is the point, each step removes the place the next one needed before.
- Zero-friction install turns encryption on, the system generates a secure key and saves it at activation
- No plaintext secrets in the database, the database no longer holds the key to all of your other systems
- Dynamic secrets sealed under a key the database does not hold
- Read-only hosts handled, not broken, the deploy model doesn’t need to be the reason security is skipped
The database can be copied, backed up, cloned to staging, left public on a shared host, and the secrets inside it are either absent or unreadable.
The vault is part of Memberium
No editing messy PHP files or waiting on access and hoping you did it right
The Secret Vault turns on at activation, moves your static credentials out of the database entirely, and seals what must stay. License Memberium and the database stops being the prize.