Security

Part of the Refresh Token Design series. I Have Shipped the Other Answer Twice Two systems I have written and published about keep a table of spent refresh tokens and treat a repeat as an attack. One uses a used_refresh_tokens table and a queue in the client. The other hashes the token and rejects the second presentation outright. That is the standard advice and I still think it is defensible. This post is about what happens when you take it out, which the previous post in this series did, and what that actually costs once you look at the code rather than the intention. ...

What This is a nine part series on refresh token rotation, session records, and device binding, built around one claim: the JWT in your auth system is not a stateless assertion, and treating it as one is what makes the design complicated. A JWT is three useful properties. It expires on its own, it cannot be modified without invalidating the signature, and it can carry data you put there. That is a good envelope. It is not an authority on whether the person holding it should still be let in. ...

Part of the Sanchayam series. Invite-Only Signup Sanchayam is a personal finance tool. There is no public registration. New users are added by invitation from an existing user. The first user is created via a /setup endpoint that is only active when the database has no users. An invitation is a row in the invitations table: CREATE TABLE invitations ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), token_hash VARCHAR NOT NULL UNIQUE, label VARCHAR, email VARCHAR, expires_at TIMESTAMP NOT NULL, used_at TIMESTAMP, created_by UUID NOT NULL REFERENCES users(id), created_at TIMESTAMP NOT NULL DEFAULT NOW() ); The token itself is never stored - only its SHA-256 hash. The invitation link sent by email contains the raw token. When the signup form is submitted, the backend hashes the submitted token and looks up the hash. If the row exists, is not yet used, and has not expired, signup proceeds and used_at is set. The raw token cannot be reconstructed from the hash, so a database leak does not expose valid invitation links. ...

Part of the MediaBridge series. The Design Premise Most access control systems respond to violations with a 403. You tried to access something you should not have - here is a polite rejection. Come back when you have the right permissions. MediaBridge takes a different position. Certain violation types are not mistakes. A user navigating to a URL they are not supposed to reach is an accident. A user constructing a request with a path outside their assigned root prefix is not. The system treats the latter as an active intrusion attempt and terminates the session immediately, rather than returning a 403 and letting the session continue. ...

Part of the PurelyManage series. The Problem Migrating an organization’s email means moving every mailbox from the old provider into PurelyMail. Each mailbox requires the source IMAP credentials: the email address and password the user logs in with on the old system. The naive way to collect these is to email everyone a spreadsheet and ask them to fill in their passwords. That spreadsheet then sits in someone’s inbox or a shared drive, plaintext, accessible to anyone who can read it. It is also error-prone: users mistype passwords, the admin has no way to know if a credential is correct until the migration job fails. ...