backlog: file #1245 -- an admin password reset re-arms bootstrap retirement and disables the account - #365
Merged
Conversation
…rement and disables the account Found while adjudicating the ASVS 6.1.1 re-score, not by looking for it: the recovery route docs/SECURITY.md now prescribes is the route that destroys the account, on a system with more than one administrator. admin_reset_password sets must_change_password=True, which is the same flag _retire_superseded_bootstrap reads as "still unclaimed". The retirement runs at the head of _login_local for the bootstrap username, ahead of the credential check, so the next login attempt disables the account and the temporary credential the administrator just issued can never be used. Re-enabling does not help: the flag is still set and another administrator still exists, so the next attempt retires it again. No route clears the flag except the self-service password change, which needs the session the reset revoked. The docstring immediately above the gate asserts this cannot happen. That claim holds for a self-service password change, which clears the flag, and fails for an administrator reset, which sets it. Recording that explicitly because it is why the defect survived review, and the fix has to correct the sentence too. Both ends of the failure are silent: the administrator sees a successful reset, the holder sees a generic invalid-credentials refusal that is deliberately indistinguishable from a wrong password. The retirement is audited, but nothing surfaces it where either party would look. The item bounds itself: the chain was read statically and each line confirmed individually, not reproduced by executing a login sequence, and the confirming test does not exist yet.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Files one backlog item. Docs-only:
docs/BACKLOG.md, +29 lines, 0 deletions, pure append.#1245 -- an administrator password reset re-arms bootstrap retirement and disables the account.
The defect
admin_reset_passwordsetsmust_change_password=True. That is the same flag_retire_superseded_bootstrapreads as "the bootstrap is still unclaimed".So: reset the password of a local account named
admin, on a system that has any other enabledadministrator, and the next login attempt disables the account ahead of the credential check. The
temporary credential just issued can never be used. Re-enabling re-triggers it. No route clears the
flag except the self-service change -- which needs the session the reset just revoked.
The recovery route is the destruction route.
Why it survived review
The docstring at
auth/service.py:580-581asserts this cannot happen, and it is right about aself-service change, which CLEARS the flag. It is wrong about an administrator reset, which SETS
it. The item says so explicitly, because the fix has to correct that sentence and not just the code --
a fix that leaves the docstring standing re-teaches the same wrong model to the next reader.
Scope bound -- please do not lose this if you summarise the item
This is a strong STATIC finding, not a demonstrated one. The chain was read at
origin/mainwithevery line confirmed individually. It has not been reproduced by executing a login sequence, and
the confirming test does not exist. That bound is written into the item body deliberately and should
survive into whatever closes it.
Verification
e7c16805, matching the filing session's report2d11daccis currentorigin/main-- fresh branch, not stacked on the #1243 headthe filing session split them deliberately rather than adding a second unrelated item to an armed PR
+29 -0alloc.ps1), leak guard passedparse_items: #1245 present, OPEN, exactly one status bannerSeverity is written in the conditional per CLAUDE.md section 0.