Signing in
One door: a six-digit code sent to your email. There is no password to leak and no magic link: the link was removed rather than kept as a second path, because two doors is two attack surfaces and one of them is always the weaker.
A code lives 10 minutes.
Codes are stored as an HMAC keyed on a server secret, not as a bare hash. The distinction is the whole point: a six-digit code has about twenty bits of preimage space, so an unkeyed digest of one is precomputable on a laptop in under a second, and a read-only database leak would have handed over every login code in flight. An HMAC requires the secret too, and a secret does not live in a database backup.
The stored value also binds the address the code was issued for, so a row lifted from the table cannot verify for a different account.
Sessions
| | | |---|---| | Remembered device | 30 days, sliding from last activity | | Not remembered | 24 hours of inactivity |
Sliding, not fixed: the cookie is re-issued on navigation, so a daily-active user is not signed out on day 30 with no warning.
The unremembered window is a day rather than a browser-session cookie on purpose — the complaint that produced this policy was unwanted sign-outs, and a crashed tab should not cost you a session.
Rate limiting and lockout
Sending a code is rate-limited per IP. Verifying carries the lockout, and that split is deliberate: when the send path also enforced the lockout, an attacker could post five wrong codes and lock the victim out of their own account entirely. The lock belongs where the guessing happens.
The tenant boundary
Every query is scoped to an organization. Roles and per-member permissions are described in Organizations & roles; the enforcement is not a UI concern: a route that reads organization data resolves the caller's membership first.
Credentials at rest
Shopify access tokens and connector tokens are encrypted with AES-256-GCM. API keys BoostEcom issues are stored as SHA-256 hashes: we cannot show you a key again after creation because we do not have it.
Tokens are never returned by an API and never logged.
Audit log
Security and billing events are written to an audit log, and global
admin actions to a separate one. You can read your own activity at
/account/settings/activity.
Reporting something
If you find a vulnerability, tell us through /contact
rather than a public thread. The
acceptable-use policy and the
security page carry the formal terms.