Password and Token Handling: Generate, Check, and Revoke a Test Credential
Try a 24-character password, compare token length units, separate hashes from HMAC, and rehearse credential replacement with a test account.
Use disposable examples to learn the settings before handling an account credential. A generated string becomes a working credential only when your server or identity provider registers it, limits its permissions, and supports revocation.
Tools in this guide
1. Generate a password against an actual account policy
Open Password Generator, choose Random characters, set Character length to 24 and Count to 1, and select the character types the destination accepts. Generate and check that the result has 24 characters. Changing a setting clears the result; generate again before copying.
Each position is sampled from the combined selected pool. Selecting uppercase, lowercase, numbers, and symbols does not guarantee at least one of each. If the destination requires every category, check the result against that rule; this tool has no policy preset or custom exclusion list.
The Small word list mode uses only 51 public words. Even six words plus its two-digit suffix provide about 40.5 estimated bits under its sampling model. Keep it for demonstrations, not production account passwords; use random characters or a passphrase generator with a much larger word list. Never reuse a published example as a secret.
2. Treat the strength score as feedback
For a disposable comparison, enter Qwerty123 in Password Strength Checker and inspect the common-pattern and sequence feedback. Compare it with a newly generated test value. The score is a local heuristic, not a breach lookup or proof that an attacker cannot guess a password.
Do not use the displayed score as a backend acceptance threshold. The account system must enforce its own password policy and authentication controls. An accepted test password, rate limiting, and account recovery are separate checks that this page cannot perform.
3. Read token units before copying
In Token Generator, select Base64url, set Random length to 32 bytes, Count to 2, and leave the prefix empty. Each result should contain 43 unpadded characters representing 256 random bits. A prefix such as demo_ adds five visible characters but no random bits.
For comparison, 32 HEX characters represent 16 random bytes, or 128 bits. Do not copy the number 32 between formats and assume the same strength. Configure scope, expiry, and revocation in the receiving service; generating or copying a Bearer line does not create those controls.
4. Separate text fingerprints, message authentication, and password storage
In Hash Generator, calculate the SHA-256 digest of abc, then change the input to abd and calculate again. The digest changes, but neither digest proves who sent the text. This tool hashes UTF-8 text; entering report.pdf hashes that name, not the file bytes.
For a disposable HMAC comparison, use message order=42 and key demo-key in HMAC Generator and inspect HMAC-SHA-256. Repeating both inputs gives the same result; changing the message to order=43 changes it. The server must authenticate the agreed message bytes with its secret key. This published key is only a fixture, and HMAC does not encrypt the message or stop replay by itself.
Do not store account passwords as plain SHA-256 or HMAC outputs. Use a dedicated password-hashing implementation, such as Argon2id or an appropriately configured bcrypt implementation, within the account system.
5. Rehearse replacement in a test service
Use a disposable account in a service you control. Register a generated credential as demo-v1 with one read-only permission, then make one allowed test request and record the credential ID and result, not the credential value. If the service issues its own keys, use its issuer instead of pasting a locally generated token.
Create demo-v2 with the same narrow permission and a defined expiry. Update the test client through its secret configuration, verify a successful request with v2, then revoke v1. Retry v1: the expected result is the service’s documented authentication failure. Verify v2 still works, remove the test credentials, and record the elapsed replacement time.
If v1 still succeeds, investigate cached credentials, replicas, and revocation propagation before claiming the drill passed. Revoking an API key does not automatically revoke unrelated sessions or previously issued tokens. Never put either value in screenshots, tickets, source control, or the drill report.