logaritmisk/biggus-dickus
1
0
Fork 0
Code Issues 17 Pull Requests Actions Packages Projects Releases Wiki Activity

Login hardening: rate-limiting/lockout + password-strength policy #20

New Issue
Open
opened 2026-06-02 13:22:29 +00:00 by logaritmisk · 0 comments
logaritmisk commented 2026-06-02 13:22:29 +00:00
Owner
Copy Link
Copy Source

Context

Email/password login (POST /api/admin/login) currently verifies argon2id and mitigates user-enumeration timing (verify_dummy), but has no brute-force protection and only a minimal password floor (≥8 chars, enforced at create-user). Post-MVP hardening.

What to do

  • Rate limiting / lockout on the login endpoint — per-IP and/or per-account attempt throttling with backoff or temporary lockout. (No Redis in MVP; an in-process limiter or a small DB-backed counter fits the single-tenant model.)
  • Password-strength policy — beyond the 8-char floor: a configurable minimum and optionally a breached-password / common-password check at user creation and any future password-change endpoint.
  • Optional: a CSRF double-submit token in addition to SameSite=Strict (defense in depth for the admin surface).

References

  • crates/api/src/admin.rs — login handler (verify_dummy on miss)
  • crates/server/src/lib.rs — create_user (the ≥8 char check)
  • crates/auth/src/lib.rs — hash_password/verify_password
  • Surfaced in the auth plan's "Login hardening (post-MVP)" note.
## Context Email/password login (`POST /api/admin/login`) currently verifies argon2id and mitigates user-enumeration timing (`verify_dummy`), but has **no brute-force protection** and only a minimal password floor (≥8 chars, enforced at `create-user`). Post-MVP hardening. ## What to do - **Rate limiting / lockout** on the login endpoint — per-IP and/or per-account attempt throttling with backoff or temporary lockout. (No Redis in MVP; an in-process limiter or a small DB-backed counter fits the single-tenant model.) - **Password-strength policy** — beyond the 8-char floor: a configurable minimum and optionally a breached-password / common-password check at user creation and any future password-change endpoint. - Optional: a CSRF double-submit token in addition to `SameSite=Strict` (defense in depth for the admin surface). ## References - `crates/api/src/admin.rs` — `login` handler (`verify_dummy` on miss) - `crates/server/src/lib.rs` — `create_user` (the ≥8 char check) - `crates/auth/src/lib.rs` — `hash_password`/`verify_password` - Surfaced in the auth plan's "Login hardening (post-MVP)" note.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
logaritmisk
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: logaritmisk/biggus-dickus#20