Security Practices

How this site handles your account, your data, and the credentials behind it. Written to be read by anyone — no configuration details, addresses, or account names appear here.

Your password is never stored

Passwords are put through scrypt, a deliberately slow, memory-hard one-way function, together with a random per-account salt. What's stored is the result — not the password, and not an encrypted copy of it. There is no key and no procedure that turns it back into your password, because the information simply isn't there any more.

When you sign in, what you typed is put through the same process and the two results are compared. That's how the site can confirm your password is correct without ever knowing what it is. The administrator can reset an account — replacing the stored value so a new password works — but cannot look one up.

The random salt means two people who happen to choose the same password have completely different stored values, so it isn't possible to tell that they match, and precomputed cracking tables don't apply.

Password reset links

A reset link contains a single-use, time-limited random token. Only a hash of that token is stored, so the link that reaches your inbox is the only usable copy. Someone reading the database would find nothing they could redeem.

Least privilege between systems

The site generates a daily written recap using a language model. The machine running that model needs a way to receive work and return text — and nothing more, so that's all it can do:

• It has a dedicated database account restricted to a single table of generated text, and within that table only to the specific columns it must write. It cannot read participant records at all — names, email addresses, and phone numbers are outside its reach entirely, enforced by the database rather than by convention.
• That account only functions from the one machine it was issued for. A copy of the password is useless anywhere else.
• The connection is outbound only. The model machine accepts no incoming connections, so there is no way in even if the web application itself were compromised.
• The work it accepts is rate-limited, so no amount of queued requests can monopolise it.

Text produced by the model is filtered before it's shown to anyone: only a small set of formatting tags survives, and HTML attributes are removed entirely, so generated content cannot introduce active code into a page.

Account and session protection

• Sign-in attempts are rate-limited, so passwords cannot be guessed by brute force.
• Session cookies are inaccessible to page scripts, restricted to this site, and sent only over an encrypted connection.
• All form submissions carry an anti-forgery token, so another site cannot cause your browser to act on your behalf.
• Administrator sessions expire after a period of inactivity.
• Database queries are parameterised throughout — values are never assembled into query text, which is the mechanism behind SQL injection.

How credentials are handled

• Secrets are supplied to the application at runtime from the environment. None are committed to source control, and every change is automatically scanned for accidentally committed credentials before it can be deployed.
• They are not built into the application image, so distributing or rebuilding it never distributes a secret.
• Every credential is scoped to one purpose and one place, so the consequences of any single one being exposed are bounded and known.
• There is a documented rotation procedure for each one, and it's exercised — credentials are replaced when there's reason to, not left in place indefinitely.

What we don't claim

No system is perfectly secure, and a page claiming otherwise should be read sceptically. What's described here is a specific, verifiable set of measures, each chosen because it contains a specific failure. Two things follow from that honesty:

• Contact details are readable by the administrator. Email addresses and phone numbers have to be usable to send you mail, so they can't be hashed the way passwords are. They are kept behind the tightest access controls in the system, and no automated component can reach them.
• This is a hobby bracket pool, run by one person, holding names, email addresses, phone numbers, and tournament picks. It is not a bank. The practices above are proportionate to that — deliberately chosen rather than assumed, and reviewed as things change.

Found something that looks wrong? Please report it rather than testing it against other people's accounts — it will be taken seriously and fixed.

Curious how a change gets from an idea to something running here, and what stops a mistake before it reaches this page? See How This Gets Built Safely.