Encryption in transit and at rest

All of Ministrium’s operations pass through modern encryption layers. This page describes what is encrypted, with which algorithm, and where keys are managed.

Summary

In transit

Every connection to Ministrium uses TLS 1.2 or higher:

• HTTPS required on all public domains. HTTP requests are automatically redirected to HTTPS.
• HSTS (HTTP Strict Transport Security) enabled with preload, telling the browser never to use HTTP for our domains.
• Managed certificates by Replit and Cloudflare, with automatic rotation.
• TLS 1.0 and 1.1 disabled on the server side.
• Modern cipher suite: prefers AEAD (AES-GCM, ChaCha20-Poly1305) and Forward Secrecy.

Internal connections between components (API → database, API → object store) also use TLS within the cloud environment.

At rest

Database

The PostgreSQL database (managed by Neon) encrypts all data at rest with AES-256. Keys are managed by Neon in their KMS (Key Management Service) and rotated per their policy. Backups and snapshots inherit the same encryption.

Object store

Attachments (photos, documents, receipts) are stored in an object store with AES-256 at rest and geographic replication for resilience.

Backups

Automatic daily backups and point-in-time recovery snapshots are kept encrypted with AES-256. See retention details in Security Overview.

Passwords

User passwords:

• Never stored in plaintext, not even in temporary logs.
• Hashed with bcrypt and a cost factor of 12 (configurable upward; never downward).
• Each hash includes its own random salt.
• When the bcrypt cost factor is changed, existing hashes are updated on the user’s next valid login.

For password policy and MFA, see MFA and password policies.

Session tokens

The session tokens the API returns to the client are JWTs (JSON Web Tokens):

• Signed with a secret that lives in Replit’s secrets manager.
• Short expiration (typically 15 minutes for the access token).
• Renewed with revocable refresh tokens that the API validates against a list of active tokens.
• On sign-out, the refresh token is revoked immediately.
• On password change or detection of a suspicious session, all of the user’s active tokens are revoked.

Application secrets

Credentials the application uses to talk to external services (Stripe, SendGrid, Twilio, customer integrations) are stored in Replit’s encrypted secrets manager:

• Never in the source code of the repository.
• Never in logs: logging pipelines filter any pattern that looks like a key or token.
• Never in error reports that developers see.
• Access to the manager restricted to a small group of the Ministrium team with MFA and quarterly review.

Field-level encryption keys

Some especially sensitive fields (health information under HIPAA, certain minors’ data under COPPA) are encrypted at the field level with specific keys that live in Replit’s KMS:

• Keys are rotated annually.
• Data in queries is decrypted only when an authorized role queries it.
• Each decryption is logged in the audit.

Encryption testing

We verify encryption configurations periodically:

• SSL Labs A+ on all public domains.
• Automated scans of TLS configuration in CI before each deployment.
• Annual external audit of configuration as part of SOC 2. See SOC 2.

Next steps

• MFA and password policies
• Audit and logs
• SOC 2