What Is scrypt? Memory-Hard Password Hashing Explained

Here's a claim that sounds wrong until you follow the money: scrypt is harder to crack than bcrypt for reasons that have almost nothing to do with being a better scrambler of bits. Both take a password and produce a fixed-length value nobody can reverse. What scrypt adds is a demand for memory — a large block of it, needed all at once, for every single guess — and that one requirement is what quietly bankrupts an attacker's cheapest weapon.

To see why memory is the lever, you have to look at how passwords actually get cracked, and what the attacker is really buying.

Why fast hashes lose

When a password database leaks, nobody reverses the hashes — hashes don't reverse. The attacker guesses: run a candidate password through the same hash, compare, repeat, billions of times. A plain SHA-256 is catastrophic here precisely because it's fast and cheap to run in parallel. A modern GPU computes billions of SHA-256 guesses per second; a purpose-built ASIC does far more. Speed, the virtue that makes SHA-256 great for checksums, is a liability the moment you're storing passwords.

The defensive move is to make each guess deliberately slow. That's what bcrypt does with its cost factor, covered in bcrypt password hashing explained — it burns CPU time so an attacker gets thousands of guesses per second instead of billions. But bcrypt uses a fixed, small amount of memory (about 4 KB). That leaves one door open: an attacker can build hardware with thousands of tiny cores, each doing bcrypt in its own sliver of the chip, because 4 KB per core is nearly free to provide.

The jigsaw-table picture

Think about the difference between a task that takes time and one that takes space. Assembling a thousand-piece jigsaw takes hours no matter how clever you are — that's the CPU-cost defense. But it also takes a whole table's worth of space to spread the pieces out at once. One person with a big dining table can do it. Now imagine ordering a thousand people to each assemble their own puzzle simultaneously: suddenly you don't need a thousand pairs of hands, you need a thousand tables. The room runs out of floor long before it runs out of people.

That's memory-hardness. scrypt forces each guess to fill and repeatedly read a large block of RAM — you can dial it up to many megabytes. An attacker with a thousand cracking cores now needs a thousand blocks of fast memory running in parallel, and fast memory is the expensive, space-hungry part of any chip. The cheap-parallelism advantage that GPUs and ASICs rely on evaporates. That's the entire idea, and everything else in scrypt is machinery in service of it.

What scrypt actually does

Under the hood scrypt runs in three movements. First it uses PBKDF2 — the classic key-stretching function — to expand your password and salt into a starting block of data. Second — the memory-hard core, called ROMix — it fills a large array with a long chain of derived values, then makes a sequence of pseudo-random reads back into that array, each read depending on the last. Because the access pattern can't be predicted ahead of time, the whole array has to stay resident in memory; you can't cheaply recompute pieces on demand. Third, it runs PBKDF2 once more to produce the final output. The salt threads through all of it, which is why a unique salt per password matters exactly as much here as it does for defeating a rainbow table.

The three knobs: N, r, p

scrypt exposes three parameters, and understanding them is most of understanding scrypt:

• N — the CPU/memory cost factor. It must be a power of two, and it's the main dial. Raising N scales both the work and the memory a single hash consumes, roughly linearly. This is where most of your security budget goes.
• r — the block size. It sets how much memory each unit of N represents; larger r means bigger, more cache-unfriendly memory operations. r = 8 is the standard choice.
• p — parallelism. How many independent mixing lanes run. p = 1 is common for password storage; you raise it only when you specifically want to use multiple cores per hash.

A widely-cited modern baseline is N = 2^15 or 2^16, r = 8, p = 1 — but the number that matters is the one you measure. Set the parameters so a single hash takes roughly 250 milliseconds on the machine that actually runs in production: slow enough to punish an attacker, fast enough that your login endpoint survives a crowd. Copying a value from a 2013 blog post is the same mistake as copying bcrypt's "rounds = 10" — it silently leaves you far too fast.

scrypt vs bcrypt vs Argon2

The three deliberately-slow password hashes line up on one axis — how they make an attacker's hardware expensive:

• bcrypt — CPU-hard, fixed ~4 KB memory. Battle-tested since 1999, universal library support, no practical break. Its ceiling is that small memory footprint.
• scrypt — memory-hard since 2009, standardized in RFC 7914. Tunable memory cost closes bcrypt's hardware gap; its subtlety is that a careless time/memory parameter trade can be exploited.
• Argon2 — the 2015 Password Hashing Competition winner, memory-hard with cleaner, more independent controls over memory, time, and parallelism. The recommended default for greenfield systems.

If you're choosing between the two memory-hard options, Argon2 vs bcrypt walks the same reasoning to a verdict — and the short version is that scrypt and Argon2id are close cousins, with Argon2id getting the nod for new builds and scrypt being an entirely respectable, well-supported alternative. For the wider question of when any algorithm "breaks" versus merely ages, MD5 vs SHA-256 vs bcrypt draws the lines.

Where scrypt fits today

Reach for scrypt when you want memory-hardness and value a decade-plus of real-world deployment — it's baked into OpenSSL, Node's crypto module, and countless libraries, so you rarely implement it yourself. It's a fine choice for password storage and for deriving encryption keys from passphrases. For a brand-new system with no constraints, Argon2id is the current default recommendation; for an existing scrypt deployment with sane parameters, there's no urgency to migrate.

And remember what a slow hash does and doesn't do. It protects the stored value against offline cracking. It does nothing for a password that was guessable to begin with — a memory-hard hash of "summer2026" is still one dictionary word away from cracked. You can feel the cost yourself in the bcrypt hash generator (bump the rounds and watch the delay grow, the same intuition scrypt's N gives you), confirm a password matches a stored hash with bcrypt compare, and hash raw values with the SHA-256 generator to feel how instant a fast hash is by contrast. Then start every account from strength by minting real secrets with the password generator, because entropy is the half of the job no algorithm can do for you — the same point made in what makes a strong password.

The takeaway

scrypt is a deliberately slow, deliberately memory-hungry way to hash passwords and derive keys. Its defining trick isn't cleverer scrambling — it's forcing every guess to occupy a large block of RAM at once, which turns an attacker's cheap parallel hardware into an expensive real-estate problem. Tune N (and r, p) to about 250 ms on your own hardware, salt every password, and treat it as one of three good answers — bcrypt, scrypt, Argon2 — rather than the only one. Make each guess cost space, not just time, and the economics of cracking stop working in the attacker's favor.