All packsMulti-Tenant Auth & RBAC CoreSolve
session token hashing postgres store hashed not plaintext
A stolen database backup shouldn't hand out live sessions
Storing session and invite tokens in plaintext means a database read (a backup, a replica, a compromised query) is equivalent to stealing every active login.
What goes wrong
If the sessions table stores the literal cookie value a browser sends, then anyone who can read that table -- a database backup, a read replica, a SQL injection elsewhere in the app, an over-broad admin query -- can use those values directly to impersonate every currently logged-in user, no additional cracking required. The cookie and the stored value being identical turns any read access into full session takeover.
Why agents get it wrong
Storing the token as-is is the simplest thing that makes a login system work, and functionally it's indistinguishable from the hashed version in every normal test -- login works, logout works, sessions expire on schedule. The difference only matters in a scenario (someone reads the database who shouldn't) that a functional test suite has no reason to simulate.
What Multi-Tenant Auth & RBAC Core pre-decides
Core decision 14 issues a 32-byte crypto.randomBytes token for each session, stores only its SHA-256 hex in the database, and applies the identical discipline to invite tokens in decision 15. The verify suite asserts directly that no stored value in the database equals the plaintext cookie or invite token a client would actually hold -- reading the table gives an attacker nothing they can use.
Source: ARCHITECTURE.md core decision 14-15