Bcrypt vs Scrypt

Bcrypt's Blowfish-based core requires only around 4 KiB of working memory regardless of how high its cost factor is set — the cost factor scales CPU rounds, not memory. This is exactly what makes Bcrypt attractive to attackers building dedicated cracking hardware: a chip with very little memory per core can still run a Bcrypt guess, so thousands of cores can be packed onto a single board.

Scrypt's defining feature is that its cost function scales three separate parameters: N (a CPU/memory cost factor, required to be a power of two), r (block size, affecting memory bandwidth usage per iteration), and p (parallelization). Raising N forces the algorithm to allocate and repeatedly read/write a memory buffer whose size grows with N — commonly tens of megabytes for password-hashing configurations. An attacker's custom hardware now needs that same large memory allocation per parallel guess, which is vastly more expensive to fabricate at scale than adding pure compute cores.

The practical result: Scrypt-cracking hardware exists, but it's meaningfully more expensive per guess-per-second than Bcrypt-cracking hardware, because memory (not raw logic gates) is the more costly resource to scale in custom silicon.

Bcrypt has exactly one tuning knob — the cost factor, an exponent controlling the number of Blowfish key-setup rounds. This simplicity is a genuine advantage: there's very little a developer can misconfigure, and every mainstream language has a mature, well-tested Bcrypt library.

Scrypt's three parameters (N, r, p) interact with each other in ways that are easy to get wrong: an under-tuned N provides little real memory-hardness benefit, while an over-tuned N can allocate more memory per login attempt than a server can afford under concurrent load, risking out-of-memory conditions during a traffic spike or a deliberate denial-of-service attempt. Choosing safe, effective Scrypt parameters requires more deliberate thought than Bcrypt's single-value tuning.

Bcrypt also carries its well-documented 72-byte password truncation limit (inherited from Blowfish's key schedule) — any characters beyond the 72nd byte are silently ignored. Scrypt has no such practical length limit, since its construction is built on top of PBKDF2 and HMAC-SHA256 rather than a fixed-size cipher key.

Bcrypt's two-decade track record means it's implemented, audited, and battle-tested across effectively every server language and framework, with predictable, well-understood behavior. This maturity is a real security asset in its own right — a newer algorithm with less real-world scrutiny carries more implementation-risk uncertainty, even if its theoretical design is stronger.

Scrypt is also mature and standardized (RFC 7914) and is well-supported in most modern languages' cryptography libraries, though it sees somewhat less default usage in general-purpose web frameworks than Bcrypt or, increasingly, Argon2 — the industry's current default recommendation for new systems (see Bcrypt vs Argon2). Scrypt remains most prominent today in systems that adopted it early for its memory-hardness (certain cryptocurrency wallets and key-derivation contexts) rather than as the default suggestion for a brand-new password database.