add rate limiting and 2fa hardening

README.md

@@ -52,7 +52,10 @@ The project is designed for self-hosted/private deployments. It is not a full en
 - Recovery codes are stored only as hashes.
 - Recovery codes can be downloaded as a text file after generation.
 - Recovery codes can be regenerated from account settings.
+- Recovery-code count warnings in account settings.
 - Recovery codes are one-time use.
+- The setup secret is only stored after the first valid authenticator code.
+- Existing refresh sessions are revoked when 2FA is enabled or disabled.
 
 ## Current Status
 
@@ -60,8 +63,8 @@ MiauInv is an active private project. The current version supports core inventor
 
 - Avatar support is currently only represented by a placeholder in the UI.
 - There is no dedicated admin panel yet.
-- There is no rate limiting yet for login, 2FA, or recovery-code attempts.
-- Automated test coverage is still incomplete and should be expanded around authentication, 2FA, recovery codes, and inventory handlers.
+- Basic in-memory rate limiting protects login, 2FA, refresh, registration, and sensitive account endpoints.
+- Automated testing is currently limited and will be expanded in future releases.
 - The application currently uses native TLS. If deployed behind a reverse proxy, the proxy must connect to the backend over HTTPS or the backend TLS behavior must be adjusted intentionally.
 
 ## Technical Stack
@@ -101,7 +104,7 @@ More detailed documentation is available in:
 
 - [Authentication](docs/AUTHENTICATION.md)
 - [Database](docs/DATABASE.md)
-- [Testing](docs/TESTING.md)
+- [Security](docs/SECURITY.md)
 
 ## Configuration
 
@@ -168,8 +171,8 @@ openssl rand -base64 48
 | `/api/userinfo` | `GET` | Yes | Same user information handler as `/api/profile`. |
 | `/api/account/username` | `POST` | Yes | Changes the current username after password confirmation. |
 | `/api/account/password` | `POST` | Yes | Changes the current password, revokes old refresh tokens, and issues a new session. |
-| `/api/2fa/setup` | `POST` | Yes | Creates a pending TOTP secret and returns `secret`, `otpauth_url`, and a base64 PNG QR code. |
-| `/api/2fa/enable` | `POST` | Yes | Enables 2FA after validating a TOTP code. Returns one-time recovery codes. |
+| `/api/2fa/setup` | `POST` | Yes | Creates a pending TOTP secret and returns `secret`, `setup_token`, `otpauth_url`, and a base64 PNG QR code. |
+| `/api/2fa/enable` | `POST` | Yes | Enables 2FA after validating the temporary setup token and a TOTP code. Replaces recovery codes and revokes old sessions. |
 | `/api/2fa/disable` | `POST` | Yes | Disables 2FA after password and TOTP confirmation. Revokes sessions and clears auth cookies. |
 | `/api/2fa/recovery-codes/regenerate` | `POST` | Yes | Invalidates existing recovery codes and returns a new set after password and TOTP confirmation. |
 
@@ -295,16 +298,16 @@ For Docker deployments, place Caddy and MiauInv on the same Docker network and r
 
 ## Security Notes
 
-- JWTs are signed, not encrypted. Do not put secrets into JWT claims.
+- JWTs are signed, not encrypted. Normal access and purpose tokens must not contain secrets. The temporary 2FA setup token is a narrow exception because it carries the not-yet-enabled TOTP secret back to the authenticated browser until confirmation.
 - `JWT_SECRET` must be random and private.
 - Access tokens expire after 15 minutes.
 - Refresh tokens expire after 7 days and are rotated on refresh.
 - Refresh tokens and recovery codes are stored in the database as hashes.
 - TOTP secrets are currently stored in the database because the server must validate codes. Protect the database file accordingly.
-- Recovery codes are only shown when generated. Users should download or copy them immediately.
+- Recovery codes are only shown when generated. Users should download or copy them immediately. The UI warns when few unused codes remain.
 - 2FA disable and recovery-code regeneration require both the current password and a valid TOTP code.
-- The project should add rate limiting before being exposed to untrusted public traffic.
-- The project should add more automated tests around login, 2FA, recovery codes, and account settings before being considered production-ready.
+- Basic in-memory rate limiting is enabled for login, 2FA, refresh, registration, and sensitive account endpoints. Use persistent or distributed rate limiting for multi-instance deployments.
+- Automated testing is currently limited. Authentication, 2FA, recovery codes, rate limiting, account settings, and inventory handlers should be covered before production use.
 
 ## Screenshots