What problem does this solve?
Large credential sprays over slow or unstable links can take hours. If the process is interrupted (network drop, Ctrl-C, system reboot), all progress is lost and the operator must re-run from the beginning. This wastes time and causes duplicate bad-password counter increments for credentials that were already tested.
Proposed solution
Add --resume <state-file> support. CredWolf would save progress to a state file after each credential attempt, recording which user/secret pairs have been tested. On resume, it skips already-tested pairs and continues from where it left off.
State file should track:
- The original command-line options (to detect mismatched resumes)
- Set of completed
(user, secret_hash) pairs (hash the secret to avoid storing plaintext credentials in the state file)
- Per-user salt cache (to avoid redundant salt retrieval requests)
- Per-user status (principal_unknown, revoked, wrong_realm) to preserve skip logic
- Timestamp of last attempt
File format options:
- SQLite — robust, handles concurrent writes, easy to query
- JSON lines — simple, append-only, human-readable
The --resume flag should error if the state file's original options don't match the current invocation (different domain, target, protocol, etc.).
Alternatives considered
- Piping output through
tee and using --exclude-file on re-run — doesn't preserve internal state (salt cache, revoked users, lockout counter)
- Checkpointing at the user level instead of per-attempt — simpler but loses progress within a user's password list
What problem does this solve?
Large credential sprays over slow or unstable links can take hours. If the process is interrupted (network drop, Ctrl-C, system reboot), all progress is lost and the operator must re-run from the beginning. This wastes time and causes duplicate bad-password counter increments for credentials that were already tested.
Proposed solution
Add
--resume <state-file>support. CredWolf would save progress to a state file after each credential attempt, recording which user/secret pairs have been tested. On resume, it skips already-tested pairs and continues from where it left off.State file should track:
(user, secret_hash)pairs (hash the secret to avoid storing plaintext credentials in the state file)File format options:
The
--resumeflag should error if the state file's original options don't match the current invocation (different domain, target, protocol, etc.).Alternatives considered
teeand using--exclude-fileon re-run — doesn't preserve internal state (salt cache, revoked users, lockout counter)