The closing password-testing exception conflicts with the absolute no-login rule
Source references: 4Earlier text says never authenticate with a leaked credential, even with a client’s verbal blessing. The closing line then says working for the subject is the only situation in which “testing a password” is appropriate, without limiting “testing” to an offline Pwned Passwords prefix query.
A user could interpret the later sentence as permission to try a leaked password on the client’s account, causing insufficiently authorized access, account lockout, security alerts, or computer-misuse violations.
Earlier text categorically forbids authenticating with leaked credentials, resets, and cross-service reuse tests, and presents the range API as the legitimate check that avoids recovery. The closing statement nevertheless calls work for the subject the only situation where “testing a password” is appropriate. “Testing” may mean the range API, but the sentence does not say so and could be read as permitting authentication. Users should ask the author to state explicitly that only local hashing and k-anonymity lookup are allowed, never submission to login or recovery flows.
This assessment concerns the code and conditions shown, not proof that harm has occurred.**Never use a leaked credential to authenticate to anything.** Not to "confirmthe account exists". Not on a test account. Not on the subject's account with aclient's verbal blessing. Credential stuffing is unauthorized access undercomputer-misuse law in most jurisdictions, and the public availability of thepassword is not a defence — see [../../ETHICS.md](../../ETHICS.md).The same applies to derived actions: do not attempt password resets, do not userecovered security-question answers, and do not try a recovered password on adifferent service to test reuse. Reuse is something you *infer* from data youalready hold, never something you test.Show 3 other places
Practically: pull the minimum fields needed for the objective, do not retaincredentials at all, store case material encrypted at rest with access logged,and delete on a schedule you wrote down at the start. If you are working for asubject on their own data, that is the cleanest footing available — and it isthe only footing on which testing a password is ever appropriate.You hash the password with SHA-1 locally and send only the **first five hexcharacters** of the hash to the range endpoint. The service returns every hashsuffix in its corpus beginning with that prefix, along with how many times eachhas been seen. You compare locally.security posture, which is genuinely useful in a due-diligence context. Thenstop. Cracking a hash produces a credential you are not allowed to use, so thework has no legitimate output. The exception is a self-audit or an authorizedsecurity assessment where the password holder is your client, and even then therange API answers the question without cracking anything.