Skip to main content

max / makenotwork

5.3 KB · 173 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 - DDoS protection via CDN (Cloudflare)
98
99 ### Monitoring
100
101 - Structured logging
102 - Failed login tracking
103 - Security headers (CSP, X-Frame-Options, etc.)
104
105 ---
106
107 ## What If We're Compromised
108
109 An attacker who gains full access to our systems would get:
110
111 - All stored data (content, contacts, transactions)
112 - Session tokens (could impersonate users)
113 - Encrypted backups (if they get the keys)
114
115 They would not get:
116
117 - Plaintext passwords (only hashes)
118 - Past sessions (expired tokens)
119 - Data you've deleted (within retention limits)
120
121 This is why you should:
122 - Use a unique password for this site
123 - Enable 2FA
124 - Export your data regularly
125 - Revoke sessions you don't recognize
126
127 ---
128
129 ## Incident Response
130
131 If we detect a breach:
132 1. Immediate containment
133 2. User notification within 72 hours
134 3. Detailed post-mortem published
135 4. Guidance on protective steps if PII is exposed
136
137 ---
138
139 ## Vulnerability Disclosure
140
141 Found a security issue?
142
143 1. Email security@makenot.work
144 2. Include detailed reproduction steps
145 3. Give us 90 days before public disclosure
146 4. We'll credit you (unless you prefer anonymity)
147
148 We respond within 48 hours and don't pursue legal action against good-faith researchers. No bug bounty program currently.
149
150 ---
151
152 ## Verification
153
154 ### Source Available
155
156 All code is publicly available for review. Verify our security claims, check for vulnerabilities, and report issues responsibly.
157
158 Repository: [makenot.work/git/max/]https://makenot.work/git/max/
159
160 ---
161
162 ## Future Work
163
164 - **Hardware security modules** for key storage
165 - **Third-party audit** when resources allow
166 - **Bug bounty program** when scale justifies
167
168 ## See Also
169
170 - [Content Protection]./content-protection.md: how we protect creator content
171 - [Privacy Policy]../legal/privacy-policy.md: data handling policies
172 - [Guarantees]../about/guarantees.md: platform commitments
173