Pin down the password-reset rules

Raised by: Lena (Security) · Priority: High · Component: Auth / password reset

Goal

The platform team is about to move password reset onto the new auth service. Last time a refactor like this went out, a reset link kept working after it had been used and nobody noticed for a month. The current code follows the rules from security review SEC-58 (listed in README.md), but almost none of them are tested. Write the tests that would fail if the refactor breaks any of them.

You are writing tests, not changing the code. Put them in tests/ (for example tests/test_reset_rules.py). The fixtures in tests/conftest.py give you a fake clock you can advance(), a users store with maya@example.com (password correct horse battery) and a resets service wired to both; conftest.py itself can't be changed.

Requirements

Cover these rules through the public API (request_reset, redeem, change_password, check_login):

• A reset link works once.
• It is valid for 30 minutes: it still works just before, and is expired at exactly 30:00.
• Requesting a new link invalidates older links for that account.
• A link whose secret has been modified is rejected (and the real one still works).
• A rejected new password (too short, contains the email name) does not use up the link.
• Changing the password in account settings invalidates outstanding links.

Acceptance

• Your tests must all pass on the current code; a test that fails on correct code scores zero.
• We run them against several realistic broken versions of the reset code. Each counts as caught when at least one of your tests fails on it. Your score is the share caught.
• Only test files count. Aim to finish in about 10 minutes.