Security

How we protect your account and data: password hashing, 2FA, session management, encryption, and content scanning.

Account Security

Passwords

Minimum 8 characters, maximum 128
Hashed with Argon2id (memory-hard)
We cannot read your password
Breach detection via a public breach database (hash prefix only, your password is never shared)

Two-Factor Authentication

Passkeys (WebAuthn/FIDO2): hardware keys or platform authenticators
TOTP-based (any authenticator app)
Backup codes for recovery
Required for API key generation
Optional but strongly recommended

Session Management

Sessions expire after 7 days of inactivity
View active sessions in Settings > Security
Revoke any session remotely
New device/location triggers email notification
Cookies: HttpOnly, Secure, SameSite=Lax (Lax rather than Strict to support OAuth redirect flows)
Session rotation on privilege change

Encryption

In Transit

Data	Protection
All web traffic	TLS 1.3
API requests	TLS 1.3
Database connections	TLS

HSTS enabled. Certificate transparency logging.

At Rest

Data	Protection
Database	AES-256 disk encryption (infrastructure-provided by hosting provider)
Object storage	AES-256 server-side encryption (infrastructure-provided by storage provider)
Backups	AES-256 disk encryption (infrastructure-provided)

Encryption at rest is infrastructure-level (Hetzner), protecting against physical theft and infrastructure compromise. No application-level encryption layer; the platform has server-side access to stored data (necessary for indexing, search, and content delivery).

What this means in a breach scenario. If a database dump were obtained without the disk-encryption key, an attacker would get only ciphertext. If an attacker reached the running process or a decrypted backup, the following would be readable as-is: email addresses, account metadata, content metadata, and second-factor seeds (TOTP secrets are stored unencrypted at the application layer). Passwords are not affected: they are stored only as Argon2id hashes and cannot be recovered from a dump. Backup codes are stored as hashes. Passkey credentials are public-key material and are not secrets. We plan to move TOTP seeds behind an application-level key so that a database-only compromise does not yield working second factors; until then, treat TOTP as protecting against credential reuse and phishing, not against a server-side breach.

What We Can Access

We protect your data from external attackers. We have server-side access to data we host. That’s how the platform works.

We Can See

Your content (text, audio, video files)
Transaction records
Contact shares between fans and creators
All metadata (who, when, what)

This is necessary for search indexing, content policy enforcement, and customer support.

We Won’t

Sell your data
Share it without legal requirement
Access it without business need
Keep it after you delete your account

See Privacy Policy for legal commitments.

Payment Security

Payments handled entirely by our payment processor
We never see or store card numbers
PCI compliance handled by the payment processor
Direct payouts to creator-controlled accounts

Infrastructure Security

Server Hardening

Firewall (only ports 80, 443, 22)
SSH key authentication only
Automatic security updates
Rate limiting on auth endpoints
Servers in SOC 2 certified data centers
Network segmentation
DDoS protection via CDN

Monitoring

Structured logging
Failed login tracking
Anomaly detection
Security headers (CSP, X-Frame-Options, etc.)

What If We’re Compromised

An attacker who gains full access to our systems would get:

All stored data (content, contacts, transactions)
Session tokens (could impersonate users)
Encrypted backups (if they get the keys)

They would not get:

Plaintext passwords (only hashes)
Past sessions (expired tokens)
Data you’ve deleted (within retention limits)

This is why you should:

Use a unique password for this site
Enable 2FA
Export your data regularly
Revoke sessions you don’t recognize

Incident Response

If we detect a breach:

Immediate containment
User notification within 72 hours
Detailed post-mortem published
Free credit monitoring if PII exposed

Vulnerability Disclosure

Found a security issue?

Email security@makenot.work
Include detailed reproduction steps
Give us 90 days before public disclosure
We’ll credit you (unless you prefer anonymity)

We respond within 48 hours and don’t pursue legal action against good-faith researchers. No bug bounty program currently.

Verification

Source Available

All code is publicly available for review. Verify our security claims, check for vulnerabilities, and report issues responsibly.

Repository: makenot.work/git/max/

Future Work

Hardware security modules for key storage
Third-party audit when resources allow
Bug bounty program when scale justifies