YanoSecA candidate is a proposed password. A check may submit that candidate to a running login service or compare derived data against a local stored record. The place of the comparison determines whether the service participates and can count the attempt.
Online guessing sends an attempt to an authentication service. Offline guessing compares candidates against permitted copied verification data without that login service in the loop. A rate limit slows or stops repeated service attempts; a lockout pauses an account after a rule is triggered. These controls do not count comparisons that happen outside the service.
Before you begin
- Recommended first
- The rule for every tool from here on, Notes: scope, command, result, time, Passwords, hashes, and dumps, Access control and IDOR
- Estimated time
- 14 min reading, 14 min activity. Setup and optional practice may take longer.
- Where you work
- Use only the supplied North Desk fictional cards and source in a desktop or mobile browser. Keep predictions in private notes. No login attempt, recovery tool, framework module, permission change, domain setup or target connection is required. Optional later lab setup has a separate budget.
- Without a lab
- All evidence needed for the activity appears on this page. Copy it into notes if downloads are unavailable. Read the labeled model and predict each result; a paper trace practises the reasoning while tool operation waits for a lab. Reading needs no JavaScript. Answer checking needs JavaScript and a secure context; saving progress also needs usable browser storage.
After this lesson you can:
- Classify a printed trace by whether an endpoint would receive the candidate.
- Copy the budget and the lockout stop from the grant.
- Keep a service trace and a file trace under different limits.
01Example
Fresh authored classification model. No login or file comparison is executed.
Case W: candidate → running lab login → failure response
The service participates and can record the attempt.
Case X: candidate → local stored-value comparison → match/miss
No login endpoint receives it.
Both cases still need permission and an explicit stopping rule.02Where the candidate goes
Three online patterns have different target distributions: brute force tries many passwords for an account, password spraying tries a small set across accounts, and credential stuffing reuses known account/password pairs from elsewhere. All involve service-facing attempts. No such attempt is part of this activity.
An account-based counter can limit repeated login failures, while lockout itself can deny access to the legitimate user. Offline protection instead depends on safeguarding stored data and using suitable salted, costly password derivation. Possessing a file never creates permission to use it.
The packet uses labels such as V-mint, assigned by its author. They are not password hashes. NIST uses verifier to mean the checking service; these cards sometimes say stored verifier label for the synthetic comparison value. Keep that narrower worksheet meaning explicit.
Locate where password checking happens and explain which controls can limit each kind of attempt.Model. A teaching model drawn by hand. It shows the idea, not real tool output.
Read the full explanation below.
Playback is optional. Step through at your own pace.
- Candidate source → Running lab loginCase W: candidate to loginThe running service participates and can record the attempt.
- Running lab login → Candidate sourceFailure responseAuthored Case W response, not a new login attempt.
- Candidate source → Local stored-value comparisonCase X: local comparisonThe local check returns match/miss; no login endpoint receives it.
In Case W the running service participates.
Follow the explanation
- In Case W the running service participates.
- In Case X the local comparison receives the candidate.
Read every state and value
1. In Case W the running service participates.
- Messages shown
- online · Failure response
- Current message
- Failure response
- Policy decisions
- Status: not-established
- Participant roles
- Actor: Candidate source; Text: Both cases still need permission and an explicit stopping rule. · Actor: Running lab login; Text: Can record this modeled attempt. · Actor: Local stored-value comparison; Text: Case X local stored-value comparison receives no login endpoint.
2. In Case X the local comparison receives the candidate.
- Messages shown
- offline
- Current message
- offline
- Policy decisions
- Status: not-established
- Participant roles
- Actor: Candidate source; Text: Local comparison still needs permission and a stop rule. · Actor: Running lab login; Text: Case W running lab login participates and can record the attempt. · Actor: Local stored-value comparison; Text: Match/miss stays local; no endpoint receives the candidate.
03Classify two activity traces
The supplied S-4 and F-4 traces use synthetic words. Read their routes and the budget without submitting anything.
North Desk limits
Label: original fictional scope. No account was attacked.
Grant: read these printed traces.
Target: the traces themselves. Not a school portal, not a club login, not a VPN peer.
Allowed action: classify where a comparison happens, and copy the budget.
Time: this reading.
Budget for a service trace: 3 attempts, then stop.
Stop: lockout line L-2. A paused account is a reason to stop, not a reason to continue.
Possession of a verifier file is not permission to keep guessing.
A synthetic label is not a password you may reuse.
North Desk guessing flows
Label: original fictional traces. Nothing is submitted on this card. You do not need to start 127.0.0.1:8443.
Worked service trace W-1
Target printed on the card: http://127.0.0.1:8443/login
Candidate 1: pine-4. Card result: generic failure.
Candidate 2: pine-5. Card result: generic failure.
Candidate 3: pine-6. Card result: lockout line L-2, account desk-lab paused.
Budget: 3. Stop at L-2. Do not invent a fourth candidate.
pine-4, pine-5, and pine-6 are synthetic labels for this card. Do not type them into a real login.
Worked local trace W-2
File: verifier-mina.txt, on the card only.
Stored label: V-mint. Compared locally with three assigned labels.
No address and no login path.
Activity trace S-4
Printed endpoint: http://127.0.0.1:8443/login
Candidate shown: birch-2. The card says the endpoint would receive it.
Budget: 3. Stop if lockout line L-2 is the next printed result.
birch-2 is synthetic. Do not submit it.
Activity trace F-4
File: verifier-birch.txt, on the card only.
Stored label: V-birch. Comparison stays on the file.
No endpoint is named.
- Copy the budget of three and stopping line L-2 from scoped-limits.txt. Those limits do not authorize actual login attempts here.
- Find S-4’s endpoint and F-4’s file. For each, draw where a candidate would go and whether a login service receives it.
- Check your route descriptions: S-4 names the endpoint for birch-2; F-4 names verifier-birch.txt with no endpoint. Explain which control is in the service path rather than merely writing a category.
- Stop at the written comparison. A lockout or missing grant is a stopping condition, never a reason to change addresses.
04Optional challenge
For about ten optional minutes, write an incident-safe stop note: the synthetic account desk-lab is paused at L-2, no further attempt is made, and the limit is recorded. Explain why an account lockout must not be bypassed by moving to another address.
05Fresh cases for the checks
Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.
Route card A: fictional comparison pathsOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
A1: candidate → running login service → failure response.
A2: candidate → local copied verification record → match/miss; no service contact.
A3: candidate → another running login service → lockout response.
Read the paths only. No attempt is made.
Budget card B: independent grantsOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
B1 service plan: at most 5 attempts, stop sooner on lockout.
B2 local-file plan: exactly the 4 printed comparisons, then stop.
Neither plan authorizes changing the target or adding candidates.
Stop card C: separate printed service traceOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
Limit: at most 6 attempts; stop on lockout, even before 6.
C1 first attempt: failure.
C2 second attempt: failure.
C3 third attempt: account locked.
C4 proposed fourth attempt: not performed.
Changed grant DOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
A file is available locally. Its owner has authorized reading its filename only. No candidate comparisons are granted.
06Explain the evidence and its limit
Optional self-check: explain why a service lockout affects an online trace but does not count local-file comparisons.
Review your note: name where each comparison occurs, keep each grant and count separate, and stop when either a count or earlier condition ends the task. Do not describe any actual attempt.
07Common mistakes
If online means only a public website, trace the endpoint: a loopback lab service is still a participating service.
If the service’s rate limit is expected to count local comparisons, draw the path and note that no attempt reaches it.
If a card word is reused as a password, stop; these are invented data labels for reasoning, not credentials to submit.
References
- NIST SP 800-63B-4: Strength of passwords
Official background on online/offline checking, authentication controls or the named tool’s role; no commands are required.
- OWASP Authentication Cheat Sheet
Official background on online/offline checking, authentication controls or the named tool’s role; no commands are required.