How to Choose Parameters for KDFs like Argon2, Bcrypt, Scrypt, PBKDF2, Balloon Hashing, & More (Part 1 of 2) | Multifactor Blog

How to Choose Parameters for KDFs like Argon2, Bcrypt, Scrypt, PBKDF2, Balloon Hashing, & More (Part 1 of 2)

2025-06-25

Most applied cryptographers will at one point or another face the challenge of correctly configuring dozens of obscurely-named KDF security parameters: ttt, mmm, ppp, rrr, costα, σ0, ∮ (okay, that last one was made up, but you get the point…). On one hand, setting these values too low makes your system vulnerable to brute-force attack. On the other hand, setting them too high creates undue latency for end users, causing frustration and increasing churn. Moreover, as new hardware is released, the “ideal” KDF values are constantly changing and evolving over time!

We, too, faced this dilemma when configuring safe defaults for MFKDF2, so we designed a robust, future-proof methodology that strikes the right balance for any memory-hard KDF. We’re here to systematically solve the problem of KDF parameter selection for you, once and for all.

Part one of a two-part series on KDF security parameters.

Introduction

In this piece, we describe a simple, browser-based tool we’ve built to provide up-to-date guidance on how to select parameters for various different key derivation functions (KDFs). This is not only a helpful general resource for the security community, but will be particularly useful for the Multi-Factor Key Derivation Function 2 (MFKDF2), as this scheme allows for updateable parameters without changing the underlying derived key. This means that using MFKDF2 will provide you with a scheme that gets continually harder for attackers over time, without any UX detriment. We’ll discuss this further in a moment. But first, what exactly is a Key Derivation Function (KDF), and why do we want them to be “hard”?

Background on KDFs

KDFs are used when we want to turn a modest source of entropy (often user-supplied, e.g., a password) into a random looking key that can be used for cryptographic operations (e.g., encryption and decryption). KDFs have prolific use in many widely-used systems, such as full-disk encryption (e.g., Bitlocker), logging into websites (e.g., Lastpass), connecting to a WiFi hotspot (e.g., WPA/WPA2).

Hard KDFs

Unlike many computer operations, we actually want certain KDFs to be slow. For instance, the password-based KDFs (PBKDFs) are designed to be tunable so that they can be made slower over time as computers become increasingly fast. The primary reason for the desirable slowdown is to significantly increase the cost and time an attacker must spend to guess a KDF input, such as a password. When a password database is breached, attackers can use high-powered hardware, such as Graphics Processing Units (GPUs) and Application-Specific Integrated Circuits (ASICs), to perform billions of password guesses per second. As soon as attackers are able to reverse these passwords, they can start using them to create chaos, such as by conducting credential stuffing attacks. Given that the average data breach goes undetected for almost 9 months, the more we can slow attackers down in this process, the better.

KDF difficulty comes in two main flavors, and a newer third:

Time-hardness introduces a configurable computational cost, meaning the KDF algorithm is deliberately slow. By increasing a "work factor" or "iteration count," developers can make the process of hashing a single password take a fraction of a second on a standard server. For a legitimate user, this delay is negligible. However, for an attacker attempting to try billions of passwords, this small delay for each guess multiplies into an impractically long time, potentially years or even centuries. This parameter may be referred to as cost, NNN, ccc, iterations, or ttt.

Every KDF can be made time-hard by running the algorithm for multiple iterations. This hardness increase hits every device equally since there is no way of parallelizing around this!

Memory-hardness adds another layer of defense by requiring a significant amount of RAM to compute the hash. This directly counters the parallel processing power of GPUs and ASICs, which have vast computational capabilities but relatively limited and slower memory access per processing unit. By forcing each hash computation to consume a substantial amount of memory, memory-hard KDFs limit the number of parallel guesses an attacker can perform simultaneously, thereby leveling the playing field between the defender's server and the attacker's specialized hardware. In particular, this type of hardness strongly prevents ASICs from being used as ASICs are specialized to running a distinct circuit – so while they may be able to quickly iterate through a hash (e.g., work quickly with time-hardness), they cannot generalize to handle a changing memory parameter! This parameter may be referred to as memory, memory size, mmm, block size, or rrr.

In essence, these properties ensure that even if an attacker steals a database of hashed passwords, the cost and time required to crack them are prohibitively high, rendering the stolen data of little value.

Parallelization is an additional line of defense that can be used to slow down attackers in a disproportionate manner. Basically, parallelization describes the number of independent threads that should be used to compute the hash. For example, if this was set to two, then operations are roughly twice as quickly computed on two entirely separate threads. Now, for a user that has two threads available, if this took 500ms to compute, then they’re happy, but an attacker may have wanted to use many threads to attack the hash in parallel. In this case, if the attacker had 100 threads to use, they are now getting the effect of 50 when this parameter is set to two. This parameter may be referred to as parallelism, parallelization factor, or ppp.

In certain constrained environments such as a web browser, parallelization is not really useful. It will be slower for a user since there aren’t memory-independent threads to access in the browser context. At least, not at the time of writing this.

A Comparative Look at Prominent KDFs

The following are the most popular KDFs in use today, and thus are the ones we are mainly interested in analyzing in this post:

PBKDF2 (Password-Based Key Derivation Function 2)

Bcrypt

Scrypt

Argon2

Balloon Hashing

For new applications, Argon2id or Balloon Hashing are the generally recommended choice, offering the most robust and flexible protection available today.

Argon2 won the Password Hashing Competition and NIST suggests Balloon Hashing in SP800-63b due to its provable security. Still, despite being best-in-class both have known issues that make them weaker in practice than in theory.

Multifactor’s KDF Parameter Suggestions

That’s a whole lot of options (and options-within-options) to choose from! Let’s make it easy.

Today we are releasing the first version of our client side “Interactive KDF Benchmark” tool. You can find this tool at https://kdf.multifactor.com.

Using with MFKDF2

As a reminder, here at Multifactor, we’re building the Multi-Factor Key Derivation Function v2.0 (MFKDF2), a KDF designed to compose multiple traditional factors (i.e., passwords, HOTP/TOTP, hardware/software tokens, OOBA, etc.) to derive a static key. By design, MFKDF2 is updatable, meaning that after you have initialized and derived a key, you can later reconstitute the factors used to derive the key without changing the key itself. This doesn’t just mean that you can do something like reset your password or create a new TOTP key; it also allows you to actually update the parameters used for the internal KDFs, making them harder to attack over time!

This means that MFKDF2 can provide adaptable security. As the speed of processors increases, or attacks are found on specific hashes/KDFs, you can reconstitute your MFKDF2 policy with heightened security parameters all while deriving the same key. No other KDF alone can boast this feature!

Conclusion

This post and the Interactive KDF Benchmark serve as a vital resource for security practitioners seeking guidance on KDF selection and parameter optimization. MFKDF2 will build upon this foundation, continuously increasing difficulty to ensure a dynamic and robust defense against evolving threats. Our aim is to empower the security community with the tools and knowledge necessary to implement state-of-the-art KDF practices.