Auth security model
Isolation, hashing, rate limits, enumeration, and what staff can never see.
The boundary that matters most
Your application's users are not Flares users. Separate tables, separate tokens, separate
meaning. Nothing in your pool can reach cloud.flaresinc.com,
admin.flaresinc.com or ops.cloud.flaresinc.com, and no Flares Account
is created by anyone signing into your app.
Project isolation
Every query is scoped by project before it runs — there is no way to ask about a user without naming whose pool. Access tokens are signed per project, so a token from project A fails signature verification in project B rather than merely failing a lookup.
Passwords
- Hashed with argon2id (bcrypt cost 12 where argon2 is unavailable).
- Never logged, never returned, never displayed — no endpoint or screen exposes a hash.
- Verification is constant-time; a missing user still burns a hash comparison so timing does not reveal which failure it was.
- Flares staff cannot read them either. Not "policy" — there is no code path.
Rate limiting
| Operation | Limit | Keyed by |
|---|---|---|
| Sign-in | 10 / 5 min | project + address + email |
| Sign-up | 20 / hour | project + address |
| OTP request | 5 / 10 min | project + address + email |
| OTP redeem | 10 / 10 min, plus 5 attempts per code | project + address + email |
| Password forgot | 5 / 10 min | project + address + email |
| Verification resend | 5 / 10 min | project + address |
| Refresh | 60 / min | project + address |
Account enumeration
Sign-in, password-forgot and OTP-request answer identically whether or not the address exists. Console and secret-key admin endpoints do say plainly that an email is taken — those callers are already authorized to know.
Secrets at rest
- Refresh tokens: only SHA-256 hashes are stored.
- Verification, reset and OTP secrets: hashed, bound to project and purpose, single-use, expiring.
- A dump of the control-plane database yields no usable credential.
What Flares staff can see
Operations sees whether Auth is on, how many identities and sessions a project holds, and whether it is suspended. Staff can suspend the service or revoke every session in an incident — both attributed and audited. Staff cannot browse your users, read their metadata, or recover a password. Suspension and its effects →