CruxDevCruxDev Tools Prompts
security Utility • Zero-Server Privacy • 100% Client-Side

Scrypt / Argon2id Hasher

Modern password hashing with scrypt and Argon2id — configure memory, iterations, and parallelism for OWASP-compliant outputs.

Overview

Formats password-hashing output in the PHC string syntax for Argon2id and scrypt - $argon2id$v=19$m=65536,t=3,p=4$... or $scrypt$ln=16,r=8,p=4$... - with tunable memory, time and parallelism parameters. One honest note: the digest inside is produced by PBKDF2-SHA-512, so these are format demonstrations rather than hashes a real Argon2 or scrypt verifier will accept.

How It Works

Choose Argon2id or scrypt, type a passphrase, and set the three cost parameters: memory in KiB, iteration count, and parallelism. The PHC string regenerates live as any input changes, with a fresh 16-byte salt each time. Copy the string from the output box. If parameters are out of range the tool clamps them rather than failing, and the output always shows the exact parameter names and values used.

Step-by-Step Usage Guide

  1. Pick the target format: Argon2id for modern systems, scrypt where RFC 7914 compatibility is the goal.
  2. Enter a passphrase and adjust memory, time and parallelism. Defaults of 65536 KiB, t=3, p=4 mirror common example configurations.
  3. Copy the PHC string and note how each parameter is encoded - m in KiB, ln as a power of two, all comma-separated in the metadata section.
  4. Feed the string to a schema validator or test fixture to confirm your app's parser handles the fields you actually set.

Technical Specifications & Standards

The output follows the PHC string format: algorithm identifier, version (v=19 is Argon2 1.3, in the encoded form RFC 9106 describes), comma-separated cost parameters m, t and p, then the salt and digest in unpadded base64. RFC 9106 specifies Argon2 and its variants; RFC 7914 specifies scrypt, whose encoded form uses ln (log2 of the memory cost N), r and p. What the tool does not do is run either algorithm: the digest is PBKDF2-HMAC-SHA-512 with an iteration count of timeCost times 1000 and a 256-bit output, wrapped in the PHC costume. Memory is the real differentiator - Argon2id's and scrypt's value over PBKDF2 is precisely that they resist GPU cracking by demanding memory, and PBKDF2 offers none of that - so a genuine verifier (libsodium, argon2-cffi, a scrypt module) will reject these strings. For real deployments, OWASP's baselines are the reference: Argon2id at m=19456 (19 MiB), t=2, p=1 or an equivalent trade-off; scrypt at N=2^17, r=8, p=1; and PBKDF2-HMAC-SHA-256 at 600,000 iterations if FIPS constraints force it. Use this tool to learn the syntax and produce fixture strings; use real libraries to protect users.

Targeted Use Cases

  • Generating correctly-shaped PHC strings for config file examples, documentation, and test fixtures.
  • Learning the parameter vocabulary - m, t, p, ln, r - before committing to values in a real deployment.
  • Checking that a parser in your codebase extracts salt, digest and parameters from PHC strings without choking.
  • Comparing Argon2id and scrypt encodings side by side while studying RFC 9106 and RFC 7914.

Notes & Gotchas

  • Never store these strings as real password hashes - a genuine Argon2id or scrypt verifier will reject them because the digest was not produced by that algorithm.
  • Follow OWASP's minimums for production: Argon2id m=19456, t=2, p=1; scrypt N=2^17, r=8, p=1; PBKDF2-HMAC-SHA-256 at 600,000 iterations only when FIPS compliance requires it.
  • Raise memory before raising time when tuning real Argon2id; memory hardness is what defeats GPU cracking.
  • Use a dummy passphrase here. Whatever you type exists in browser memory and on your screen, not in a secure environment.

Frequently Asked Questions

Will my application accept this hash?

Only if your code merely parses the format. A real Argon2id or scrypt implementation will reject it during verification, because the digest is PBKDF2-SHA-512 output wrapped in PHC syntax rather than the named algorithm's genuine output.

What does v=19 mean in the Argon2 string?

It encodes Argon2 version 1.3 - hexadecimal 0x13 - the version standardized in RFC 9106. Verifiers check it before parsing the cost parameters, and a mismatch is an error rather than a warning.

Why is my hash different every time?

Each run draws a fresh 16-byte salt from the browser's random generator and embeds it in the string. That mirrors how real password hashing behaves: a unique salt per hash, even for the same password.

Which parameters should I use in production?

OWASP's Password Storage Cheat Sheet lists equivalent configurations - for example Argon2id at m=19456 (19 MiB), t=2, p=1, or scrypt at N=2^17, r=8, p=1. Pick based on your available memory, and benchmark verification latency on your own servers.