A signed-in member changes their own password — why demand the current one, and where do the password rules belong?

A password change on a signed-in screen looks like a form with three boxes. The engineering sits in two questions the form does not show: what the server demands before it accepts the change, and which code the new value passes through before it is stored. ## What a session reference proves, and what it does not When a member opens the change screen on a federation's rating-submission site, the server already knows who they are: the request carries a reference to a session record issued when they signed in. That reference proves one thing — somebody signed in as this member at some earlier moment. It says nothing about who is typing now. A laptop left open at the congress hall, a shared club machine nobody signed out of, a housemate at the desk: all ordinary, boring and common. Re-entering the current password is a **knowledge proof of the exact credential being replaced**. It is narrow on purpose: | Proof offered | What it establishes | What it fails to stop | |---|---|---| | A valid session reference | Somebody signed in as this member earlier | Anyone who later reaches that signed-in browser | | A fresh challenge on the enrolled authenticator | That authenticator is present right now | Someone holding the browser and the unlocked authenticator together | | Re-entering the current password | Whoever is typing knows the secret being retired | Someone who already knows that password | The third row is the only one aimed at the credential in question. A possession challenge proves a device is present; it does not show that the person driving it knows the value they are about to replace. That is why the two controls are not substitutes. A strong answer also states the limit out loud: the re-proof does nothing against an attacker who already has the password. Stopping that is a different control's job. ## Every server path that can put a password in a member's row The second half of the subject is placement, and the argument starts by enumerating the writers rather than debating the rules: 1. **Self-registration** — a new player creates an account. 2. **Self-service change** — the member replaces their own value. 3. **An officer-initiated set** — a federation officer sets one for a player who cannot get in before a congress. 4. **A bulk import** — a club's legacy member list is loaded in one go. 5. **An internal support endpoint** — the one nobody remembers until it turns up in a review. A rule that lives only on the registration form is not a rule. It is a property of one screen. Rows arriving through the other paths will violate it, nothing will complain, and the violation stays invisible until somebody runs a query nobody has thought to write. Assume a sixth path appears next quarter, because one usually does. ## One routine behind all of them The fix is structural rather than a matter of discipline: - One routine takes the subject, the new value, and a **context** naming which path is calling. - The rule check runs there, once, for every caller. - Each path's own precondition is asserted there too: the self-service path must present a current password that verifies, while a path where no current password exists must instead prove the caller's authority to act on someone else's account. - The stored value is written and the change event emitted from the same place, so no path can write without announcing it. - Adding that sixth path becomes a call to the routine rather than a copy of its contents. Client-side checks stay, but as a convenience that saves a round trip. They enforce nothing: anything reaching the endpoint directly skips them entirely. ## The change is an event, not just a write A successful change matters to code nowhere near the form. Other parts of the system want to know that this member's credential was replaced, when, and whether the member did it themselves or somebody acted on their behalf. This routine's responsibility is that the event is emitted exactly once, from one place, for every path. What the consumers then do — what is torn down, what the member is told, what has to be re-enrolled — is decided elsewhere and is not the change endpoint's call. ## What an interviewer is listening for - That the re-proof is about the *credential*, not about the *person being present*, and that those are different claims. - That the candidate enumerates write paths unprompted instead of describing only the screen they built. - That validation and the event sit behind the paths rather than beside each one. - That the limits get said: neither control helps once the password itself is known, and client-side validation enforces nothing.