dsh-login

Exposing a dsh-web port directly on a server or LAN leaves the admin interface wide open to anyone who can reach it. dsh-login wraps the webserver with a full session gate: SPA fallbacks, /api transfers, WebSocket and SSE upgrades all pass through cookie-verified sessions before reaching the original handler, and not a single line of dsh source code is modified. It mounts purely as a Cordis bundle, so deployment is as simple as one dsh plugin install command.

Storage is where it earns its trust. Passwords are scrypt-hashed with a random salt (N=2^14, r=8, p=1) using constant-time comparison, and the entire credential file is encrypted with AES-256-GCM before it touches disk. Failed logins hit a sliding-window rate limit plus a deliberate delay, and a dummy hash is burned when the username does not exist to frustrate user enumeration. Sessions live only in memory and vanish on restart; cookies are flagged HttpOnly with SameSite=Strict to block cross-site request forgery. The primary key can be supplied via the DSH_LOGIN_SECRET environment variable, auto-generated into a 0600 key file, or (with a loud warning) fall back to a plaintext store that still benefits from scrypt hashing.

It leaves room for small teams as well. Multiple users log in independently; the web UI and the standalone CLI share the same encrypted store with mtime-based hot-reload, so an account change made from either side is picked up by the other within seconds. Enabling userWorkspaces gives each logged-in user an isolated workspace and session history visible only in their own sidebar. If you are putting dsh-web behind nginx for remote or shared team access, dsh-login is the lowest-friction lock you can add in front of it.