Security

Passwords#

• Hashed with argon2id (memory-hard: about 70 ms of CPU and 64 MiB per hash), and re-hashed on login if the parameters are ever raised.
• Hashing runs in a thread pool with a small concurrency cap, so a burst of sign-ins queues up instead of freezing every other request. The database connection is returned before hashing starts.
• Unknown emails are checked against a dummy hash, so “no such account” takes as long as “wrong password”: response time does not reveal who has an account.
• Errors are identical for both cases: 401 Incorrect email or password.

Sessions: short access tokens, rotating refresh tokens#

The app holds a 15-minute JWT access token in memory and a 30-day refresh token in the phone's secure keystore. Refresh tokens are opaque random strings, stored only as hashes, and replaced on every use. They are grouped into families, so reuse of an old one is a strong sign of theft.

Each access token also carries the user's token version. Changing or resetting the password, deleting the account or an admin suspension bumps it, which signs out every device at once.

Rate limiting across many servers#

Limits are kept in Redis, so they hold no matter how many API instances run. We use a sliding-window counter: a fixed window lets a client burst twice the limit across a window edge, while this estimate smooths the edge using just two counters per client.

# estimated = current + previous * (1 - elapsed_fraction_of_current_window)
pipe = redis.pipeline(transaction=True)      # MULTI/EXEC: atomic across workers
pipe.incr(current_key)
pipe.expire(current_key, window_seconds * 2)
pipe.get(previous_key)
current, _, previous = await pipe.execute()
estimated = int(current) + int(previous or 0) * (1 - elapsed)
if estimated > limit:
    raise RateLimited(details={"retry_after_seconds": reset})   # 429 + Retry-After

Adaptive login protection#

Plain rate limits treat a typo and a botnet the same. Before any password is hashed, the API scores each login attempt from several independent signals: recent failures for the account, the network and the device, how widely failures are spread across accounts and addresses, attack activity across the whole service, and whether this device has signed in to this account before.

Why it is cheap to defend and expensive to attack

• Many real users behind one campus or carrier address are not penalised: only failures count, never successful sign-ins.
• An attacker hammering someone's email can trigger challenges for that account, but the owner on their usual phone is never locked out.
• Challenge tokens are verified with the provider on the server, accepted once, and checked for age, hostname and action. A “success” flag from the client is ignored.
• If Redis is unavailable, a small per-server fallback still caps attempts, and real users can still sign in.

Input and transport hardening#