The Encrypted Credential Vault: Zero-Knowledge Security at MyDigitally.app
How we built military-grade encryption into your digital legacy — and audited the rest of the platform to match.
What Just Launched
A new Encrypted Credential Vault has been successfully pushed to the project. Think of this like a mini-1Password or Bitwarden built right into the app. When you view an asset, you can now securely attach passwords, API keys, or private notes to it.
Before this code went live, the latest updates from other teammates (the Friends feature, security docs, and styling tweaks) were safely pulled in and combined with it.
Zero-Knowledge Security: How It Keeps Your Data Safe
The core philosophy here is “Zero-Knowledge.” The server (and anyone running the database) has absolutely no idea what your passwords are. Here is exactly how that works, in plain English.
Your Master Passphrase Never Leaves Your Device
It lives only in your browser’s temporary memory — never sent, saved, or stored anywhere.
More detailed infoLess info
The moment you click Save, your browser scrambles your plaintext password into unreadable gibberish (ciphertext) using a highly secure military-grade algorithm (AES-256-GCM).
Only this scrambled gibberish is sent to the database — the server never sees the plaintext value.
Encryption Happens Locally
Your browser scrambles the plaintext into ciphertext with AES-256-GCM before anything reaches the network.
More detailed infoLess info
The moment you click Save, your browser scrambles your plaintext password into unreadable gibberish (ciphertext) using a highly secure military-grade algorithm (AES-256-GCM).
Only this scrambled gibberish is sent to the database — the server never sees the plaintext value.
The "Wrong Passphrase" Guardrail
The "Wrong Passphrase" Guardrail A wrong passphrase throws a clear error instead of silently returning corrupted data.
More detailed infoLess info
If you enter the wrong passphrase to unlock the vault, the system won’t just output corrupted, messy text. The algorithm checks a unique digital signature (an authentication tag).
If the signature doesn’t match, it immediately throws an error saying the passphrase is wrong — rather than silently returning garbage.
Brute-Force Protection
PBKDF2 with 100,000 iterations makes every single guess computationally expensive.
More detailed infoLess info
To stop hackers from using automated scripts to guess your passphrase, the system uses a technique called PBKDF2 with 100,000 iterations.
This essentially forces a hacker’s computer to do an immense amount of heavy math for every single guess, making brute-force attacks incredibly slow and expensive.
No Identical Blueprints
No Identical Blueprints Every saved password gets its own unique, random salt and initialization vector (IV).
More detailed infoLess info
This means if you save the exact same password (Password123) for two different accounts, they will look completely different when scrambled in the database.
The Golden Rule: No Recovery, By Design
Because the server never stores your passphrase, there is no "Forgot Password" button for the vault.
More detailed infoLess info
If you lose your master passphrase, the data is permanently lost. That’s the tradeoff that makes zero-knowledge architecture possible in the first place.
Why We Audited Everything
When you build an app designed to catalog and protect your digital legacy, security isn’t just a compliance item on a checklist — it’s the bedrock of user trust. If future customers are going to trust mydigitally.app with proof-of-ownership documents, financial asset locations, and sensitive credentials, our defenses must be flawless.
To ensure this, we recently conducted a comprehensive, plain-language security audit of our entire application architecture. Our philosophy is simple: fail fast, eliminate fallback paths, and fix root causes rather than patching symptoms.
If a malicious actor somehow breaks into our database, they won’t find a single password — only cryptographic gibberish. If you lose your master passphrase, even we cannot recover your data. This is what secure-by-design engineering looks like.
Stopping the Hidden Tracking Pixels
An unvalidated avatar URL let attackers turn profile views into a tracking beacon.
More detailed infoLess info
The problem: When users updated their profile avatar, our backend accepted the provided avatar_url without validation. While the UI nudged people to upload images to our secure storage, an attacker could bypass it entirely and submit a direct link to a malicious server (e.g. https://attacker.com/tracking.gif). Whenever another user loaded that profile, their browser would silently ping the attacker, leaking their IP address and device data.
The fix: We introduced strict server-side validation. The backend now explicitly rejects any URL that doesn’t begin precisely with our trusted storage bucket prefix.
Eliminating HTTP Header Injection in PDF Exports
A crafted display name could break out of an HTTP header and inject instructions into the networking layer.
More detailed infoLess info
The problem: When users downloaded a PDF compilation of their digital assets, the system dynamically named the file using their profile display name. A display name containing structural punctuation — quotes, semicolons — could break out of the standard HTTP header boundaries and inject malicious instructions.
The fix: Rather than trying to sanitize messy input with endless exceptions, we implemented a strict whitelist filter using regular expressions — stripping out everything except alphanumeric characters, spaces, and hyphens.
Locking Down Proof-of-Ownership Files
Ownership documents lived in a public storage bucket, reachable by anyone who intercepted a link.
More detailed infoLess info
The problem: To catalog a digital legacy, users upload purchase receipts, registration emails, and screenshots. The storage bucket holding these files was set to public. Even with unguessable, long unique IDs in the file URLs, the files themselves were technically accessible over the open internet to anyone who intercepted a link.
The fix: We rewrote our storage access policies end to end:
- Flipped the storage bucket from public = true to public = false.
- Added database-level Row-Level Security (RLS) so only the authenticated owner of an asset can request its file.
- The application now generates short-lived, 1-hour signed URLs server-side when the owner needs to view a file — once the hour passes, the link expires and breaks for everyone.
Our Uncompromising Security Ledger
A quick-reference log of every posture upgrade, kept fully transparent.
More detailed infoLess info
- Authentication Endpoints — Risk: credential stuffing & email bombing. Fix: capped at 5 OTP requests and 2 password reset emails per hour via the Supabase API layer.
- Password Reset Redirects — Risk: host header injection. Fix: swapped dynamic request headers for a hardcoded, un-forgeable NEXT_PUBLIC_APP_URL target.
- Friend Requests — Risk: column mutation exploits. Fix: upgraded Postgres RLS UPDATE policies with explicit WITH CHECK subqueries, preventing direct API attacks from altering underlying friend IDs.
- File Uploads — Risk: phishing script storage. Fix: moved file-type verification from the browser layer into the storage bucket schema layer, rejecting invalid MIME types instantly.
The Takeaway: Security Is a Process, Not a Feature
Engineering mydigitally.app taught us that simple, explicit logic always beats clever, open-ended code. By rejecting implicit trust, sanitizing every boundary, and validating user context directly from encrypted server sessions rather than parameter inputs, we have engineered a fortress for your digital legacy.
When you use our platform, you aren’t just trusting our promises — you are trusting proven cryptographic architecture and defensive engineering standards.