max / makenotwork

5.4 KB · 176 lines History Blame Raw

1	# Security
2
3	How we protect your account and data: password hashing, 2FA, session management, encryption, and content scanning.
4
5	## Account Security
6
7	### Passwords
8	- Minimum 8 characters, maximum 128
9	- Hashed with Argon2id (memory-hard)
10	- We cannot read your password
11	- Breach detection via a public breach database (hash prefix only, your password is never shared)
12
13	### Two-Factor Authentication
14	- Passkeys (WebAuthn/FIDO2): hardware keys or platform authenticators
15	- TOTP-based (any authenticator app)
16	- Backup codes for recovery
17	- Required for API key generation
18	- Optional but strongly recommended
19
20	### Session Management
21	- Sessions expire after 7 days of inactivity
22	- View active sessions in Settings > Security
23	- Revoke any session remotely
24	- New device/location triggers email notification
25	- Cookies: HttpOnly, Secure, SameSite=Lax (Lax rather than Strict to support OAuth redirect flows)
26	- Session rotation on privilege change
27
28	---
29
30	## Encryption
31
32	### In Transit
33
34	\| Data \| Protection \|
35	\|------\|------------\|
36	\| All web traffic \| TLS 1.3 \|
37	\| API requests \| TLS 1.3 \|
38	\| Database connections \| TLS \|
39
40	HSTS enabled. Certificate transparency logging.
41
42	### At Rest
43
44	\| Data \| Protection \|
45	\|------\|------------\|
46	\| Database \| AES-256 disk encryption (infrastructure-provided by hosting provider) \|
47	\| Object storage \| AES-256 server-side encryption (infrastructure-provided by storage provider) \|
48	\| Backups \| AES-256 disk encryption (infrastructure-provided) \|
49
50	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).
51
52	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.
53
54	---
55
56	## What We Can Access
57
58	We protect your data from external attackers. We have server-side access to data we host. That's how the platform works.
59
60	### We Can See
61
62	- Your content (text, audio, video files)
63	- Transaction records
64	- Contact shares between fans and creators
65	- All metadata (who, when, what)
66
67	This is necessary for search indexing, content policy enforcement, and customer support.
68
69	### We Won't
70
71	- Sell your data
72	- Share it without legal requirement
73	- Access it without business need
74	- Keep it after you delete your account
75
76	See [Privacy Policy](../legal/privacy-policy.md) for legal commitments.
77
78	---
79
80	## Payment Security
81
82	- Payments handled entirely by our payment processor
83	- We never see or store card numbers
84	- PCI compliance handled by the payment processor
85	- Direct payouts to creator-controlled accounts
86
87	---
88
89	## Infrastructure Security
90
91	### Server Hardening
92
93	- Firewall (only ports 80, 443, 22)
94	- SSH key authentication only
95	- Automatic security updates
96	- Rate limiting on auth endpoints
97	- Servers in SOC 2 certified data centers
98	- Network segmentation
99	- DDoS protection via CDN
100
101	### Monitoring
102
103	- Structured logging
104	- Failed login tracking
105	- Anomaly detection
106	- Security headers (CSP, X-Frame-Options, etc.)
107
108	---
109
110	## What If We're Compromised
111
112	An attacker who gains full access to our systems would get:
113
114	- All stored data (content, contacts, transactions)
115	- Session tokens (could impersonate users)
116	- Encrypted backups (if they get the keys)
117
118	They would not get:
119
120	- Plaintext passwords (only hashes)
121	- Past sessions (expired tokens)
122	- Data you've deleted (within retention limits)
123
124	This is why you should:
125	- Use a unique password for this site
126	- Enable 2FA
127	- Export your data regularly
128	- Revoke sessions you don't recognize
129
130	---
131
132	## Incident Response
133
134	If we detect a breach:
135	1. Immediate containment
136	2. User notification within 72 hours
137	3. Detailed post-mortem published
138	4. Free credit monitoring if PII exposed
139
140	---
141
142	## Vulnerability Disclosure
143
144	Found a security issue?
145
146	1. Email security@makenot.work
147	2. Include detailed reproduction steps
148	3. Give us 90 days before public disclosure
149	4. We'll credit you (unless you prefer anonymity)
150
151	We respond within 48 hours and don't pursue legal action against good-faith researchers. No bug bounty program currently.
152
153	---
154
155	## Verification
156
157	### Source Available
158
159	All code is publicly available for review. Verify our security claims, check for vulnerabilities, and report issues responsibly.
160
161	Repository: [makenot.work/git/max/](https://makenot.work/git/max/)
162
163	---
164
165	## Future Work
166
167	- Hardware security modules for key storage
168	- Third-party audit when resources allow
169	- Bug bounty program when scale justifies
170
171	## See Also
172
173	- [Content Protection](./content-protection.md): how we protect creator content
174	- [Privacy Policy](../legal/privacy-policy.md): data handling policies
175	- [Guarantees](../about/guarantees.md): platform commitments
176