• docs/superpowers/specs/2026-07-31-hashed-password-storage-design.md

    From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Sat Aug 1 00:24:30 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/83ce42da5c560cfdb39cd599
    Added Files:
    docs/superpowers/specs/2026-07-31-hashed-password-storage-design.md
    Log Message:
    docs: design for hashed password storage in data/user/pass.tab

    Records the evaluation of moving Synchronet off cleartext password
    storage, against a specific threat model: someone abusing a copy of
    user.tab -- including a sysop or co-sysop -- to recover passwords that
    users have reused on other systems.

    Reversible encryption is rejected outright. The named adversary holds
    the key by definition, since every server process must be able to
    recover the password to serve a login. Only a slow, salted, one-way
    hash addresses the goal, which in turn requires deprecating the challenge-response mechanisms that need password-equivalent material at
    rest: CRAM-MD5, APOP, HTTP Digest, Hotline, and the MQTT broker PSK
    table.

    Per-mechanism verifiers -- storing the two MD5 midstates so CRAM-MD5
    keeps working, as Dovecot does -- are considered and rejected. The
    verifier is a single unsalted MD5 compression, so storing several
    verifiers leaves you with the security of the weakest one. SCRAM
    (RFC 5802/7677) is recorded as the correct successor, but is not a
    prerequisite for this design.

    Credentials move to a new data/user/pass.tab rather than growing
    LEN_PASS. user.tab is the artifact that actually circulates, and its
    1000-byte record geometry has roughly 15 bytes of headroom for a maximally-populated record. The USER_PASS field gets an unmatchable
    sentinel rather than being blanked, because login.cpp treats an empty
    password as "no password required" and the hosts sharing /sbbs do not
    upgrade atomically.

    Also covers the migration strategy, the case-sensitivity problem, the
    remaining cleartext sinks, the denial-of-service risk of running an
    expensive KDF on HTTP Basic's per-request authentication, and the
    cleartext copies left behind in the rotated user.tab backups.

    Design only; no code changes.

    Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net