Hashes/Crypto

Scrypt Hash + Verify

Hash passwords with scrypt (RFC 7914, memory-hard KDF), with verification against an existing hash.


                    

Scrypt (RFC 7914) was one of the first memory-hard password-hashing algorithms: it deliberately requires a lot of RAM, not just CPU time, to make parallel brute-forcing on GPUs and ASICs harder.

How to use it

Common uses

Things to keep in mind

The N parameter (memory cost) increases both required memory and compute time exponentially — tune it to your server's actual capacity.

Scrypt has been superseded by Argon2 (the official Password Hashing Competition winner) as the recommended choice for new systems, though scrypt itself still isn't considered unsafe.

Article about this tool: Scrypt: why the algorithm needs so much memory

Frequently asked questions

How does scrypt differ from bcrypt or PBKDF2?

Scrypt is deliberately memory-hard as well as CPU-intensive, making it far more expensive to crack using GPUs or custom ASIC hardware compared to bcrypt or PBKDF2, which mainly resist CPU-based brute-forcing.

What do the N, r, and p parameters control?

N sets the CPU/memory cost (must be a power of two), r sets the block size affecting memory use per operation, and p sets parallelization — increasing any of them raises the resource cost of both legitimate use and attacks.

Is scrypt still a good choice compared to Argon2?

Scrypt remains solid and battle-tested, but Argon2 (the winner of the Password Hashing Competition) is generally recommended for new systems, since it offers more fine-grained control over memory and side-channel resistance.

How much memory does scrypt actually consume?

Approximately 128 × N × r bytes per computation. With typical parameters (N=16384, r=8) that's about 16 megabytes per hash — negligible for a single login, but significant at thousands of concurrent authentications on a server.

Where else is scrypt used besides password hashing?

Scrypt is known as a proof-of-work algorithm in some cryptocurrencies (Litecoin, for example) — it was chosen specifically for its resistance to mining on specialized ASIC hardware, unlike Bitcoin's SHA-256.

Articles: Hashes/Crypto

Hash Generator: how MD5, SHA-1, and SHA-256 differ from each other

Why MD5 is still used to verify file integrity, but not for passwords.

Checksum Verifier: how to check that a file isn't corrupted

Why a matching checksum confirms a file's integrity, but not who created it.

HMAC: how a keyed hash differs from a regular hash

Why a plain SHA-256 doesn't protect against message tampering, but HMAC does.

Bcrypt: why passwords are hashed slowly, not quickly

Why fast SHA-256 is a bad choice for passwords, and slow bcrypt is the right one.

UUID: how identifiers that almost never repeat are generated

Why UUID v4 can be generated independently on millions of machines without collision risk.

Password Generator: what actually makes a password strong

Why a long dictionary-word password is stronger than a short one with symbols and digits.

AES: how symmetric encryption works

Why the same key both encrypts and decrypts data in AES, and how that differs from asymmetric encryption.

Argon2: why this algorithm won the password hashing competition

How Argon2 defends better against GPU-based attacks than older password hashing algorithms.

TOTP: how one-time codes in authenticator apps work

Why the code in Google Authenticator works offline and syncs with the server only via time.

PBKDF2: the oldest key-stretching standard

Why the recommended PBKDF2 iteration count keeps growing every year.

X.509: what's inside an SSL certificate

What exactly the browser checks in a site's certificate before showing the green padlock.

PGP: how public-key and private-key encryption works

Why you can freely share a PGP public key but never the private one.