Authentication
This page explains how HoloMUSH authentication behaves as an operator sees it: what’s protected, what behavior to expect, and why the system is designed this way. For recovery procedures (locked-out accounts, password resets) see Authentication recovery; for the log-event, alerting, metrics, and database-table lookups see Authentication reference.
What’s protected
Section titled “What’s protected”HoloMUSH protects player credentials and sessions out of the box. No configuration is required — the security defaults are production-ready.
| Protection | Details |
|---|---|
| Password storage | Argon2id hashing (64 MB memory, resistant to GPU attack) |
| Session tokens | 256-bit opaque tokens, stored server-side |
| Username enumeration | Identical error for “not found” and “wrong password” |
| Token comparison | Constant-time to prevent timing side-channels |
| Credential transport | Tokens travel over TLS; no secrets in URLs |
Operators don’t configure password hashing or token generation. The server handles these with OWASP-recommended parameters.
Rate limiting
Section titled “Rate limiting”Rate limiting is per-username and kicks in automatically after failed login attempts.
| Failed Attempts | Delay Imposed | CAPTCHA (web only) |
|---|---|---|
| 1 | 1s | No |
| 2 | 2s | No |
| 3 | 4s | No |
| 4 | 8s | Yes |
| 5 | 16s | Yes |
| 6 | 32s | Yes |
| 7+ | Locked out | 15-minute lockout |
The delays are exponential and applied server-side. Players see progressively longer waits before the server responds to another login attempt.
Lockouts
Section titled “Lockouts”Lockouts expire automatically after 15 minutes. There is no administrative override — this is intentional so that lockouts remain effective even if an admin account is compromised. After lockout expires, the player can log in immediately with the correct password, and the failed-attempt counter resets to zero on any successful login.
There is no “unlock” command. This is a security design choice, not a missing feature. To handle a locked-out player report, see Recover a locked-out account.
Session management
Section titled “Session management”Expiry
Section titled “Expiry”Active sessions do not expire — a connected player is never kicked by a timer. When a player disconnects, the session enters a “detached” state and starts a countdown based on the session’s TTL (configured per role via ABAC, defaulting to 24 hours). If the player reconnects before the TTL expires, the session resumes exactly where they left off and the timer resets.
Detached sessions that exceed their TTL are reaped automatically by the server.
What invalidates a session
Section titled “What invalidates a session”| Trigger | Sessions Affected |
|---|---|
| Explicit logout | That session only |
| Password change | All player sessions |
| Password reset | All player sessions |
| Admin action | Targeted session(s) |
Players can have multiple concurrent sessions (different devices, different clients). Each session tracks user agent, IP address, last-seen timestamp, and currently selected character.
Instant revocation
Section titled “Instant revocation”Because sessions are stored server-side (not in signed JWTs), you can invalidate any session instantly by deleting its database row. No key rotation or token blacklisting required.
Related pages
Section titled “Related pages”- Authentication recovery — lockout and password-reset procedures
- Authentication reference — log events, alerting, metrics, database tables
- Authentication System (implementation) — how it’s built, for contributors
- Configuration — Server settings
- Operations — Health checks, metrics, and troubleshooting
- Database — PostgreSQL setup and maintenance