Security and privacy

MacroMath's security rests on several complementary layers, from the device to the database engine.

Identity and authentication

Supabase Auth — secure credentials, email verification via a one-time token (OTP) sent over SMTP (the mailer library) and encrypted account-recovery flows.
bcrypt — passwords are processed on the server with key derivation, making plaintext storage impossible.

Data encryption

State	Protection
At rest	AES-256 on the database infrastructure.
In transit	TLS 1.3.

Multitenant isolation (RLS)

Every table applies Row-Level Security at the PostgreSQL engine level. The expression evaluated on the server isolates access:

user_id = auth.uid()

A user can never access another's data. See Data model.

Local protection

App access can be gated by the device's biometric authentication (local_auth) — Face ID, Touch ID or fingerprint — protecting the session against improper physical access.

Engineering note — security audit

During prototyping and accelerated testing, some service keys (Supabase, Gemini and SMTP credentials) were hardcoded directly in the repository. This is a known security limitation: before production launch, a full migration to protected environment variables (Supabase Vault) and credential rotation is planned.

Don't use production keys in development builds. Externalizing secrets is a prerequisite for public launch.

Summary

Mechanism	Status
Email OTP (2FA)	Active
`bcrypt` for passwords	Active
AES-256 at rest	Active
TLS 1.3 in transit	Active
Per-user RLS	Active
Local biometrics	Active
Secret externalization	Planned