Generator — Tips & Tricks

Tricks for the Generator: password strength and passphrases, bcrypt or APR1 in .htpasswd, Wi-Fi QR, TOTP security, the text API, and neighbouring tools.

Back to the overview: Generator · Open the tool live: www.jpkc.com/tools/generator/

The manual explains every tab, the examples show the workflows. This page is about the decisions behind them: how strong a password really needs to be, when a passphrase is the better choice, which scheme belongs in a .htpasswd — and where the results go afterwards.

Password strength: length beats character set

  • Length is the biggest lever. Each extra character multiplies the possibilities. A 24-character password of just letters and digits is stronger than a 10-character one with every special. When in doubt, raise Length rather than fiddling with specials.
  • Use the entropy readout as your yardstick. The badge next to the buttons calculates the strength in bits. From 80 bits it says very strong — 13 characters from the full set already get there, as do 14 alphanumeric characters or a six-word passphrase with a digit.
  • Specials only where the target system plays along. Some logins, databases, or config files choke on &, /, ;, =, or brackets. That's what less specials (without those characters) and a-z + A-Z + 0-9 (alphanumeric, safe almost everywhere) are for. Exotic characters such as § or spaces aren't part of the random-password character sets anyway — all of them are plain ASCII. The only spaces appear if you pick space as the passphrase separator.
  • Exclude look-alikes when a human types it. The Exclude look-alikes switch removes 0 O o 1 l I and saves you the "was that a zero or an O?" back-and-forth when reading out or copying by hand. The smaller set costs a little entropy; at typical lengths, one or two extra characters make up for it.
  • Hex for tokens, not for humans. The a-f + 0-9 (hex) tier gives a clean, copy-friendly string for API tokens and machine keys — its small alphabet makes it poor for memorizing.
  • A passphrase for anything you have to remember. Six random words from the EFF list are easier to retain and faster to type on a phone than 14 wild characters — at comparable strength. Ideal for your password manager's master password or your computer login. What matters is that the words are truly drawn at random; a word sequence you made up yourself is far weaker.
  • Apple-style is the compact compromise. Pronounceable, segmented with hyphens, and carrying a digit and an uppercase letter — good for device or Wi-Fi passwords that have to fit into a form with a length limit. For purely machine secrets, prefer a long password from the standard character set.
  • Every value is a one-off. Generate again and the old one is gone — copy it before you regenerate. Need several? Raise How many instead of clicking repeatedly.

Choosing the bcrypt cost for .htpasswd wisely

In password hashing, slowness is the security feature: the more expensive the hash, the more expensive a brute-force attack — but also the longer the server works every time it checks a password.

  • 10 is the standard. The default in the .htpasswd tab suits most cases.
  • Go higher only with care. 12 or 14 make every guess considerably more expensive, but also every check on your server. With Basic Auth the browser sends the credentials with every request; if the server verifies the hash each time, a high cost adds up noticeably on pages with many files.
  • 5 and 8 are for tests only. For a production .htpasswd they're too fast.
  • Test vs. production. How long the computation takes here in the browser says little about your server. Pick the factor so it's still comfortable on your target hardware.

bcrypt or APR1-MD5 — and where Argon2 went

  • bcrypt belongs in the .htpasswd. It's the tool's default and corresponds to htpasswd -B; the Generator writes the $2y$ prefix, just as htpasswd -B does.
  • APR1-MD5 only as a fallback. As the note in the tool says, it works everywhere but is weak (1,000 MD5 rounds). Use it only if your server doesn't understand bcrypt — an nginx whose system crypt() lacks bcrypt, for example.
  • bcrypt stops at 72 bytes. It ignores anything beyond that; the tool warns you. The 24-character password from Generate is well below the limit.
  • Application passwords don't belong in this tab. If you want to store passwords in a database, you need bcrypt, Argon2id, or PBKDF2 in your platform's format — the Hash Generator creates and verifies those.
  • Salt is always included. The tool generates a fresh random salt for every hash, so the same password produces a different line on every click — which is correct and intended.

TOTP security

  • The secret is the key to the kingdom. Whoever holds the Base32 secret can generate valid codes at any time. Treat it like a password: transmit it securely, keep it out of plaintext logs, and store or delete it safely after setup. A plus here: the secret and codes are produced entirely in your browser and never sent to a server.
  • The clock has to be right. TOTP depends on time. If your server's or device's clock is significantly off, the codes won't match. The Epoch (UTC) and Iteration (T) info cards help debug a time skew.
  • 30 seconds is standard. Almost every service expects 30 seconds. Choose 60 seconds only if the other side explicitly requires it — otherwise the app won't accept the codes.
  • SHA-1 and six digits are the safe bet. The tool also offers SHA-256, SHA-512, and eight digits, but warns you itself: many apps, Google Authenticator among them, only support SHA-1 with six digits. Change these only if your service asks for it — and after switching algorithms, click Generate so the secret gets the matching length.
  • Check before you go live. Before you enable 2FA on a real account, type the code from your app into Check a code. ✓ valid now confirms that the app and the secret match.
  • Back up the QR/the secret. If you lose access to the authenticator, you need the secret to recover. Save QR Code or the copied secret in a safe place is your fallback.

Where hashes and codes get verified

  • .htpasswd lines are checked by the web server itself whenever someone requests the protected directory. The Generator doesn't check them; you only notice a mis-copied character at login.
  • bcrypt, Argon2id, and PBKDF2 for applications are verified by your application at login — or you test an existing hash in the Hash Generator, which comes with a verify function.
  • TOTP is verified by the service where you registered the secret. In the Generator you can cross-check beforehand with Check a code.

Wi-Fi QR for an existing network too

The Wi-Fi QR code doesn't only work with freshly generated keys. The result field in the WLAN tab is editable: replace its text with your existing key and enter the SSID. The QR code is rebuilt from the field's current content whenever the SSID, Security, Hidden setting, or key changes. Treat the saved wifi-qr.png like a password: anyone who scans it sees the key in plain text.

Text API in scripts

  • Server instead of browser. With the text API (e.g. /tools/generator/pw/32/) the server generates the values and sends them over HTTPS. For secrets that should never touch someone else's system, use the page — everything there is created locally.
  • The wpx defaults are enough. Without parameters, the API returns the same as the interface: no rotation, server address only. Only pass rotation, ip=1, or ua=1 if you knowingly accept the logout side effects.
  • Plan for the rate limit. More than 120 requests per minute and IP get an HTTP 429; the Retry-After header tells you how long to wait.

Combining with other JPKCom tools

  • Password hash or checksum? The Hash Generator does both: checksums for text and files and, in a section of its own, bcrypt, Argon2id, and PBKDF2 hashes with verification. Rule of thumb: random values, .htpasswd lines, and TOTP → Generator; password hashes for applications and data fingerprints → Hash Generator.
  • Encrypt a secret rather than hash it? If a value needs to be decryptable again (hashing isn't), use the Cryptor for symmetric encryption/decryption of text and files.
  • Inspect certificates and keys. If you've built a TLS/auth setup with the secrets generated here, you can inspect the associated X.509 certificates and CSRs with the PKI Viewer.
  • A unique ID rather than a secret. If you need not a secret key but a unique identifier (e.g. as a database key), the UUID Generator provides the right format.

More context elsewhere: the overview for the big picture, the manual for every parameter, and the examples for the step-by-step workflows. You can try everything directly in the tool.