Designed to keep case content under examiner control.
DFIR Toolkit separates hosted identity and licensing from the encrypted case workspace. This page documents the current controls and their limits.
Data boundary
The hosted service stores the minimum data needed to identify a customer and administer a subscription: email address, display name, plan, billing status, and Stripe identifiers. Case numbers, authority, evidence descriptions, examiner notes, field forms, drawn acknowledgements, and reports are not written to the hosted account database.
Device vault
Production case records and completed forms are serialized into a device-local IndexedDB vault. Before each write, the payload is encrypted with AES-GCM using a 256-bit key. A fresh 96-bit nonce is generated for every save.
The encryption key is derived from the user's vault passphrase with PBKDF2, SHA-256, a random 128-bit salt, and 310,000 iterations. The derived key is non-exportable and remains only in browser memory while the vault is unlocked.
Authentication and billing
Customers can use independent email and password authentication. Passwords are stored only as salted PBKDF2-SHA-256 hashes. Email verification and password-reset links are single use and expire. Session cookies are HTTP-only, secure, same-site restricted, and expire after 30 days. Verified customers sign in with their password, and authentication attempts are rate limited.
Stripe checkout and billing-portal sessions are created on the server. Price identifiers are selected from a server-side allowlist, and Stripe webhook events require a timestamped HMAC-SHA-256 signature within a five-minute tolerance.
Webhook event IDs are recorded to make subscription updates idempotent. Secret keys and webhook secrets are runtime environment variables and are not sent to the browser.
Backups and recovery
A user can export the encrypted vault envelope as JSON and import it on another compatible browser. The backup contains ciphertext, salt, nonce, algorithm metadata, and timestamps. It does not contain the passphrase or a recovery key.
Backups can be decrypted and verified in memory without replacing the current device vault. Restoring over an existing vault requires a typed confirmation, and the product records backup and verification timestamps inside the encrypted vault metadata.
Local writes are serialized and use revision checks to prevent a stale browser tab from silently replacing a newer vault. An unlocked vault locks after 15 minutes without activity, and the product warns when the browser does not grant persistent site storage.
If both the passphrase and an unlocked session are lost, The Waldrep Company cannot decrypt or recover the vault. Users should store encrypted backups and passphrases separately.
Threat model and limitations
- Vault encryption protects data at rest, but it cannot protect a record while the vault is unlocked in a compromised browser or operating system.
- Device security, endpoint monitoring, browser profile access, backup handling, and screen capture remain the customer's responsibility.
- The toolkit is documentation and decision support. It is not an evidence-acquisition, parsing, malware-detonation, or remote-analysis service.
- Demo records are sample data and are not a retained production vault.
- Production dependencies are checked for published security advisories before release. The product has not yet completed an independent penetration test or formal compliance certification. The Waldrep Company intends to pursue an independent security assessment as the product and agency customer base grow.
Reporting a security issue
Do not include evidence, case details, credentials, or live secrets in an initial report. Send a concise description and reproduction outline to info@thewaldrepcompany.com. We will acknowledge valid reports and coordinate remediation and disclosure based on severity.