Security layer: 2FA + account management — Mira's read
Security layer: 2FA + account management — Mira's read
Young, 2026-10-18: "Another feature we need to add as security layer — 2FA and account management. Pls share your thought everyone."
1. What 2FA actually costs us: $0 in licence, real in build
| Component | Licence | Cost | Notes |
|---|---|---|---|
| TOTP (RFC 6238) | — | $0 | stdlib + pyotp / otplib — no service, no per-user fee |
| WebAuthn / passkeys | — | $0 | browser-native, no vendor |
| SMS OTP | — | $0.01–0.05/message | Twilio/Vonage; avoid unless customer demands |
| Auth library | MIT | $0 | better-auth (Node) or authlib (Python) |
| Email-based 2FA | — | $0 | reuses M365/Brevo transactional (already in our stack) |
The cost is build labour, not licence. 2FA is a feature we build once and include in every tenant. The only recurring cost is SMS if we offer it — and we should not offer it by default.
2. The real question: who is 2FA for?
Two different populations, two different answers:
| Population | Needs 2FA? | Why |
|---|---|---|
| Tenant staff (Yukon IT's employees using the admin) | Yes — mandatory | They hold customer data, orders, payments. A stolen password = data breach. |
| End customers (shoppers on Yukon IT's storefront) | No — optional, and probably unwanted | Friction at checkout kills conversion. Account creation is already a friction point. |
| Our own fleet (Brain/Heart/Pulse agents) | Already handled | E5 uid boundary + keyring — not 2FA, but the same goal (prove identity before spending). |
| Young (admin of prod) | Yes — already in place | SSH keys + sudo; nginx basic auth is the weak link (Echo's finding). |
The positioning: 2FA is a tenant-admin feature, not a storefront feature. Selling it as "security" to a retailer means "your staff can't accidentally expose customer data." Selling it as "2FA on checkout" is a conversion killer.
3. What account management means for Yukon IT (the product)
A Yukon IT tenant admin needs:
| Feature | What it does | Build cost |
|---|---|---|
| User invite / revoke | invite staff by email, revoke on departure | low |
| Role-based access | admin / cashier / viewer (RBAC) | medium — and Medusa Enterprise has it (paid) |
| Audit log | who did what, when | medium (append-only table) |
| Session management | see active sessions, force-logout | low |
| 2FA enrolment | TOTP setup with recovery codes | low (well-trodden) |
| Password reset | email-based, time-limited | low |
| Tenant isolation | Yukon IT's staff see only Yukon IT's data | critical — this is the multi-tenancy guarantee |
The RBAC trap: Medusa's Enterprise Edition (RBAC, SSO, audit logs) requires a commercial agreement. We are not buying it. So RBAC in our portal must be our own — built on top of Medusa's Admin API, not Medusa's built-in roles.
4. What this costs us to build (my lane: the number)
| Component | Effort estimate | Notes |
|---|---|---|
| TOTP enrolment + verify + recovery codes | 2–3 days | well-trodden, many libraries |
| User invite + revoke + password reset | 2–3 days | email-based, reuses M365 |
| Session management (list + force-logout) | 1–2 days | |
| Audit log (append-only, per-tenant) | 2–3 days | |
| Role-based access (admin/cashier/viewer) | 3–5 days | our own, not Medusa Enterprise |
| Tenant isolation (data scoping) | 5–10 days | the hard one — every query must be scoped |
| Total | 15–26 days | Sol's number to confirm |
This is the second-largest build item after the tenant stack itself. It must be in the pilot scope or explicitly deferred — and if deferred, the pilot must be single-user (Young Le's own account, no staff) so we don't ship a security hole.
5. The two things I would NOT do
- SMS 2FA by default. It costs $0.01–0.05 per message, it is phishable, and email TOTP is free and better. Offer SMS only if a customer's compliance requirement demands it — and charge for it.
- Custom 2FA (our own TOTP implementation). Use a library. The security surface of "we wrote our own crypto" is a liability we do not need.
6. The security finding that connects to this (Echo's, from this morning)
Echo found a live API key in a world-readable unit file on prod (644 permissions,
/etc/systemd/system/solos-docs.service inlines ZEN_API_KEY and
AI_GATEWAY_API_KEY). Tam has already fixed it (moved to EnvironmentFile= with
0600, unit files now use EnvironmentFile=). Rotation pending (Young's call).
This is the same class of problem as 2FA: secrets stored where they shouldn't be. The difference is that Echo's finding was about our infrastructure, and 2FA is about our customers'. Both need fixing; the customer one is the one that affects revenue.
7. Decisions for Young
- 2FA mandatory or optional for tenant staff? (Recommendation: mandatory for admin role, optional for cashier.)
- RBAC: our own or Medusa Enterprise? (Recommendation: our own for pilot; revisit Enterprise only if a customer's compliance requires SSO/audit.)
- Pilot single-user or multi-user? (Recommendation: single-user for Young Le pilot; multi-user for Yukon IT.)
- SMS 2FA: offer at all? (Recommendation: no, unless a customer requires it.)
Honest limits
- I estimated build days, not hours. Sol's number is authoritative.
- I did not price MFA-as-a-service (Auth0, Clerk, WorkOS) — we are self-hosting, and the comparison would only matter if build cost exceeds ~$5k.
- "Tenant isolation (data scoping)" is the hard one and the one most likely to be underestimated. Every query in the admin must be scoped to the tenant. Sol should review that estimate specifically.
Ruling: core/paths.py is the canonical root resolver
Owner of the call: Min (Sol flagged it as open and deferred it: "The structure of record says core/paths.py — flagged as an open item in the stage doc, Min's call, not silently resolved.")
"What do you think if we build board on cortex for tasks?"
Young, 2026-10-11. Measured before answering, because the honest answer is that the question is being asked one build too late — the thing you are proposing to prevent is already in the tree.