Documentation
How to use this tool, practical use cases, and technical notes.
The PBKDF2/bcrypt/scrypt Hash Generator has a straightforward interface organized into input, configuration, and output stages. A typical session takes 3–5 minutes. Here is a detailed step-by-step walkthrough.
Step 1 — Enter the Password
Type or paste the password you want to hash into the Password field. This is the plaintext input that will be processed by each selected algorithm.
Password input considerations:
Scenario | Recommendation |
|---|---|
Testing your own implementation | Enter the same password your app uses; compare output format |
Learning algorithm differences | Use a short, memorable password like |
Penetration testing / hash cracking practice | Use a known password to generate a target hash you can then attempt to crack |
bcrypt specifically | Keep input under 72 bytes — bcrypt silently truncates longer passwords |
Security research benchmarking | Use a fixed test password to isolate the effect of parameter changes |
Important: Never enter real user passwords from a production system into any online tool, including this one. Use synthetic or test passwords only.
Step 2 — Configure the Salt
The Salt field accepts a custom salt value, or you can leave it empty to have the tool auto-generate a cryptographically random salt.
Salt Option | When to Use |
|---|---|
Auto-generated (leave blank) | Recommended for most use cases; ensures cryptographic randomness |
Custom salt (manual entry) | When testing reproducibility — given the same password + salt + parameters, a KDF must always produce the same output |
Fixed test salt | When verifying your implementation against a known-good hash from a reference implementation |
What salt does:
Salt is a random value combined with the password before hashing. Its purpose is to ensure that two users with the same password produce different hashes, and to defeat precomputed lookup tables (rainbow tables). Without salt, an attacker who obtains a hash database can crack all identical passwords simultaneously.
Salt Behavior | Without Salt | With Salt |
|---|---|---|
Two identical passwords | Produce identical hashes | Produce different hashes |
Rainbow table attack | Effective | Defeated |
Precomputation possible | Yes | No |
Step 3 — Select Hash Algorithms
Check one or more algorithm checkboxes: PBKDF2, bcrypt, scrypt. You can select all three simultaneously to compare their output formats side by side.
Step 4 — Configure Algorithm Parameters
Each selected algorithm exposes its own parameter controls.
PBKDF2 Options
Parameter | Description | OWASP Minimum (2024) | Recommended Default |
|---|---|---|---|
Iterations | Number of HMAC rounds applied | 600,000 (SHA-256) / 210,000 (SHA-512) | 600,000+ |
Hash Algorithm | Underlying PRF | SHA-256 or SHA-512 | SHA-256 (FIPS-compliant); SHA-512 for extra margin |
Iteration count effect on computation time (approximate, modern hardware):
Iterations | Approx. Time (server CPU) | Security Level |
|---|---|---|
10,000 | < 1ms | ❌ Dangerously low |
100,000 | ~5ms | ⚠️ Below OWASP minimum |
600,000 | ~30ms | ✅ OWASP recommended (SHA-256) |
1,000,000 | ~50ms | ✅ Strong |
2,000,000 | ~100ms | ✅ Future-proofed |
bcrypt Options
Parameter | Description | Minimum Recommended | Notes |
|---|---|---|---|
Cost Factor | Exponent of rounds (2^cost) | 10 (OWASP minimum) | Each +1 doubles computation time |
Cost factor to computation time mapping:
Cost Factor | Rounds (2^n) | Approx. Time (modern CPU) | Use Case |
|---|---|---|---|
4 | 16 | < 1ms | ❌ Testing only — never production |
6 | 64 | ~1ms | ❌ Too fast |
8 | 256 | ~5ms | ⚠️ Legacy systems only |
10 | 1,024 | ~100ms | ✅ OWASP minimum for production |
12 | 4,096 | ~400ms | ✅ Recommended for most apps |
14 | 16,384 | ~1.5s | ✅ High-security environments |
16 | 65,536 | ~6s | ⚠️ Too slow for most UX |
31 | 2,147,483,648 | Hours | ❌ Unusable |
scrypt Options
Parameter | Full Name | Description | RFC 7914 Default | OWASP Recommended |
|---|---|---|---|---|
N | CPU/Memory Cost | Controls total memory and CPU work; must be power of 2 | 16384 (2¹⁴) | 65536 (2¹⁶) minimum |
r | Block size | Memory block size factor; affects bandwidth | 8 | 8 |
p | Parallelization | Number of parallel threads | 1 | 1 |
Memory required = 128 × N × r bytes:
N | r | Memory Required | Computation Level |
|---|---|---|---|
16,384 | 8 | 16 MB | Low |
32,768 | 8 | 32 MB | Moderate |
65,536 | 8 | 64 MB | ✅ OWASP recommended |
131,072 | 8 | 128 MB | High |
262,144 | 8 | 256 MB | Very high |
1,048,576 | 8 | 1 GB | ✅ Libsodium interactive default |
Step 5 — Generate Hashes
Click "Generate Password Hashes". The tool computes each selected algorithm simultaneously in your browser using the Web Crypto API (for PBKDF2) and JavaScript implementations (for bcrypt and scrypt).
Step 6 — Review and Copy Results
The results panel displays the generated hash for each algorithm. Key things to inspect in each output:
bcrypt output format (Modular Crypt Format):
$2b$12$SaltSaltSaltSaltSaltSaHashHashHashHashHashHashHashHashHash
↑ ↑ ↑ ↑
| | 22-char base64 salt 31-char base64 hash
| Cost factor
Version prefix ($2b$ = current standard)PBKDF2 output: A hex or base64-encoded string representing the derived key, typically accompanied by the salt and iteration count needed for verification.
scrypt output: Derived key in hex or base64, alongside the N/r/p parameters and salt required for later verification.
Step 7 — Vary Parameters to Understand the Effect
A powerful learning pattern is to generate hashes with the same password but different parameters:
Generate bcrypt at cost 10 — note the time
Regenerate at cost 12 — observe the delay increases
Generate PBKDF2 at 100,000 vs. 600,000 iterations — compare output time
Change the salt and regenerate — observe the hash changes entirely even with the same password
This hands-on exploration builds intuition for how cost tuning works in production.
The PBKDF2/bcrypt/scrypt Hash Generator has a straightforward interface organized into input, configuration, and output stages. A typical session takes 3–5 minutes. Here is a detailed step-by-step walkthrough.
Step 1 — Enter the Password
Type or paste the password you want to hash into the Password field. This is the plaintext input that will be processed by each selected algorithm.
Password input considerations:
Scenario | Recommendation |
|---|---|
Testing your own implementation | Enter the same password your app uses; compare output format |
Learning algorithm differences | Use a short, memorable password like |
Penetration testing / hash cracking practice | Use a known password to generate a target hash you can then attempt to crack |
bcrypt specifically | Keep input under 72 bytes — bcrypt silently truncates longer passwords |
Security research benchmarking | Use a fixed test password to isolate the effect of parameter changes |
Important: Never enter real user passwords from a production system into any online tool, including this one. Use synthetic or test passwords only.
Step 2 — Configure the Salt
The Salt field accepts a custom salt value, or you can leave it empty to have the tool auto-generate a cryptographically random salt.
Salt Option | When to Use |
|---|---|
Auto-generated (leave blank) | Recommended for most use cases; ensures cryptographic randomness |
Custom salt (manual entry) | When testing reproducibility — given the same password + salt + parameters, a KDF must always produce the same output |
Fixed test salt | When verifying your implementation against a known-good hash from a reference implementation |
What salt does:
Salt is a random value combined with the password before hashing. Its purpose is to ensure that two users with the same password produce different hashes, and to defeat precomputed lookup tables (rainbow tables). Without salt, an attacker who obtains a hash database can crack all identical passwords simultaneously.
Salt Behavior | Without Salt | With Salt |
|---|---|---|
Two identical passwords | Produce identical hashes | Produce different hashes |
Rainbow table attack | Effective | Defeated |
Precomputation possible | Yes | No |
Step 3 — Select Hash Algorithms
Check one or more algorithm checkboxes: PBKDF2, bcrypt, scrypt. You can select all three simultaneously to compare their output formats side by side.
Step 4 — Configure Algorithm Parameters
Each selected algorithm exposes its own parameter controls.
PBKDF2 Options
Parameter | Description | OWASP Minimum (2024) | Recommended Default |
|---|---|---|---|
Iterations | Number of HMAC rounds applied | 600,000 (SHA-256) / 210,000 (SHA-512) | 600,000+ |
Hash Algorithm | Underlying PRF | SHA-256 or SHA-512 | SHA-256 (FIPS-compliant); SHA-512 for extra margin |
Iteration count effect on computation time (approximate, modern hardware):
Iterations | Approx. Time (server CPU) | Security Level |
|---|---|---|
10,000 | < 1ms | ❌ Dangerously low |
100,000 | ~5ms | ⚠️ Below OWASP minimum |
600,000 | ~30ms | ✅ OWASP recommended (SHA-256) |
1,000,000 | ~50ms | ✅ Strong |
2,000,000 | ~100ms | ✅ Future-proofed |
bcrypt Options
Parameter | Description | Minimum Recommended | Notes |
|---|---|---|---|
Cost Factor | Exponent of rounds (2^cost) | 10 (OWASP minimum) | Each +1 doubles computation time |
Cost factor to computation time mapping:
Cost Factor | Rounds (2^n) | Approx. Time (modern CPU) | Use Case |
|---|---|---|---|
4 | 16 | < 1ms | ❌ Testing only — never production |
6 | 64 | ~1ms | ❌ Too fast |
8 | 256 | ~5ms | ⚠️ Legacy systems only |
10 | 1,024 | ~100ms | ✅ OWASP minimum for production |
12 | 4,096 | ~400ms | ✅ Recommended for most apps |
14 | 16,384 | ~1.5s | ✅ High-security environments |
16 | 65,536 | ~6s | ⚠️ Too slow for most UX |
31 | 2,147,483,648 | Hours | ❌ Unusable |
scrypt Options
Parameter | Full Name | Description | RFC 7914 Default | OWASP Recommended |
|---|---|---|---|---|
N | CPU/Memory Cost | Controls total memory and CPU work; must be power of 2 | 16384 (2¹⁴) | 65536 (2¹⁶) minimum |
r | Block size | Memory block size factor; affects bandwidth | 8 | 8 |
p | Parallelization | Number of parallel threads | 1 | 1 |
Memory required = 128 × N × r bytes:
N | r | Memory Required | Computation Level |
|---|---|---|---|
16,384 | 8 | 16 MB | Low |
32,768 | 8 | 32 MB | Moderate |
65,536 | 8 | 64 MB | ✅ OWASP recommended |
131,072 | 8 | 128 MB | High |
262,144 | 8 | 256 MB | Very high |
1,048,576 | 8 | 1 GB | ✅ Libsodium interactive default |
Step 5 — Generate Hashes
Click "Generate Password Hashes". The tool computes each selected algorithm simultaneously in your browser using the Web Crypto API (for PBKDF2) and JavaScript implementations (for bcrypt and scrypt).
Step 6 — Review and Copy Results
The results panel displays the generated hash for each algorithm. Key things to inspect in each output:
bcrypt output format (Modular Crypt Format):
$2b$12$SaltSaltSaltSaltSaltSaHashHashHashHashHashHashHashHashHash
↑ ↑ ↑ ↑
| | 22-char base64 salt 31-char base64 hash
| Cost factor
Version prefix ($2b$ = current standard)PBKDF2 output: A hex or base64-encoded string representing the derived key, typically accompanied by the salt and iteration count needed for verification.
scrypt output: Derived key in hex or base64, alongside the N/r/p parameters and salt required for later verification.
Step 7 — Vary Parameters to Understand the Effect
A powerful learning pattern is to generate hashes with the same password but different parameters:
Generate bcrypt at cost 10 — note the time
Regenerate at cost 12 — observe the delay increases
Generate PBKDF2 at 100,000 vs. 600,000 iterations — compare output time
Change the salt and regenerate — observe the hash changes entirely even with the same password
This hands-on exploration builds intuition for how cost tuning works in production.