JPKCom DB

Generator — Tips & Tricks

Tricks for the Generator: password strength, choosing a cost factor, BCrypt vs. Argon2, TOTP security, and combining it with Hash, Cryptor, and PKI.

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, which cost factor to pick, when to use BCrypt vs. Argon2 — 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.
  • Specials only where the target system plays along. Some logins, databases, or .env files choke on §, &, /, or spaces. That's what less specials (more compatible) and a-z + A-Z + 0-9 (alphanumeric, safe almost everywhere) are for.
  • 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.
  • Apple-style is the compromise for memorable. Pronounceable, segmented with hyphens, yet carrying a digit and an uppercase letter — ideal for a master or device password a human has to type. For purely machine secrets, prefer maximum length in the standard character set.
  • Every value is a one-off. Generate again and the old one is gone — copy it before you switch tabs or regenerate.

Choosing the cost factor and Argon2 memory 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 every legitimate login takes.

  • BCrypt Cost is exponential: 10 (default) is a solid all-round value. 12 (slow) roughly quadruples the work compared to 10 (hence the "~3–8 s" note, depending on the device) — worthwhile for sensitive accounts if the login latency is acceptable. 8 (fast) only for tests or very weak hardware.
  • Argon2 Memory makes the hash memory-hard — exactly the property that slows down GPU and ASIC attacks. 64 MB (OWASP) is the recommended default. More memory (256 MB) raises security but costs noticeable compute time and RAM per hash; on shared servers with many concurrent logins it can become a bottleneck.
  • Test vs. production. What takes a few seconds here in the browser runs on your server on every login. Pick the factor so it's still comfortable on your target hardware — not just whatever was bearable in this tool.

BCrypt vs. Argon2 — and when APR1-MD5

  • New systems: Argon2id. It combines protection against GPU attacks (memory-hard) and against side-channel attacks, and is today's recommendation when your platform supports it (e.g. PHP PASSWORD_ARGON2ID).
  • Broad compatibility: BCrypt. Battle-tested, available everywhere, well understood. If your language/framework can't do Argon2 or your legacy hashes are BCrypt, BCrypt is the right call.
  • Argon2i vs. Argon2id: Argon2id is the recommended general-purpose variant; plain Argon2i is mainly for specific threat models. When in doubt, Argon2id.
  • APR1-MD5 is not a password hash for applications. It exists only for Apache .htpasswd files (Basic Auth). It's MD5-based and cryptographically weak — use it exclusively for that purpose and never to store application passwords. For those you need BCrypt or Argon2.
  • Salt is always included. The tool generates a separate random salt for every BCrypt/Argon2 hash; you don't have to manage it. Identical passwords therefore produce different hashes — 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.
  • Parameters are fixed for compatibility. The key URL uses algorithm=SHA1 and digits=6 — exactly what standard authenticator apps expect. That's by design, not a shortcoming.
  • 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 get verified

The Generator creates hashes but doesn't check them. Verification always happens on the receiving side:

  • BCrypt/Argon2 is verified by your application at login — e.g. in PHP with password_verify($input, $hash). The encoded hash carries all needed parameters, so you store nothing extra.
  • APR1-MD5 is verified by Apache itself against the .htpasswd whenever a protected directory is requested.
  • TOTP is verified by the service where you registered the code, against the current time step.

Combining with other JPKCom tools

  • A plain checksum rather than a password hash? If you don't want to securely store a password but to compare content or do an integrity check, use the Hash Generator (MD5, SHA-1, SHA-256, SHA-512, RIPEMD-160). Rule of thumb: passwords → Generator (BCrypt/Argon2), data fingerprint → 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.