# 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. Source: https://www.jpkc.com/db/en/tools/generator/tips/ Back to the overview: [Generator](https://www.jpkc.com/db/en/tools/generator/) · Open the tool live: [www.jpkc.com/tools/generator/](https://www.jpkc.com/tools/generator/) The [manual](https://www.jpkc.com/db/en/tools/generator/manual/) explains every tab, the [examples](https://www.jpkc.com/db/en/tools/generator/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](https://www.jpkc.com/db/en/tools/hash/)** (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](https://www.jpkc.com/db/en/tools/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](https://www.jpkc.com/db/en/tools/pki/)**. - **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](https://www.jpkc.com/db/en/tools/uuid/)** provides the right format. --- More context elsewhere: the [overview](https://www.jpkc.com/db/en/tools/generator/) for the big picture, the [manual](https://www.jpkc.com/db/en/tools/generator/manual/) for every parameter, and the [examples](https://www.jpkc.com/db/en/tools/generator/examples/) for the step-by-step workflows. You can try everything directly in the [tool](https://www.jpkc.com/tools/generator/).