[jffry]

My understanding is that the key derivation function chosen, argon2, is much more expensive to compute than something like the SHA family of hashes. This is a desirable property in a KDF precisely because it makes brute forcing much more difficult.

Further, argon2id incorporates strategies to make GPU parallelization less effective.

Obviously this won't protect you against something like a dictionary attack, there's nothing that can magically protect you if you choose a low-entropy password, just something that can make the process more difficult.

[tyingq]

It does seem like talking about dictionary attacks in the article would be helpful. Without some reference as to how many argon2 hashes per minute is reasonably possible with the shown settings, we're flying a little blind.

[woodruffw]

I performed a rough estimate in my comment up the thread, using ~2s per Argon2id with a time cost of 3. TL;DR is that you probably wouldn't want to have an extremely common password with this scheme.

[stouset]

There's no KDF in the world that can protect you if your password is in a top-10,000 list or exposed elsewhere alongside your username.

[tyingq]

Right, but that's sort of what I was getting at. The article doesn't talk much about the password other than it's "insecure". It's probably worth mentioning that a dictionary attack at some multiple of ~2/per-second/per-core is possible. So it's not just top-10,000 list, but maybe "top million" or more that's a bad idea.

[woodruffw]

Yes, I think that's what the GP was trying to say. The post doesn't qualify "insecure" meaning "not best practices" vs. "insecure" meaning "your password is an extremely common one."

[Grimburger]

> there's nothing that can magically protect you if you choose a low-entropy password

Ignoring the extra time for decryption there's no difference between a unique low-entropy password that takes 2 years to bruteforce and a high-entropy password that takes 2 years to bruteforce.

[jffry]

Yeah, if you a very common password like "hunter2" or "Password1", then even with a KDF that takes 100ms to generate the key, it's still very feasible to run through the 100k most common passwords and compromise it within a few hours.

If we're talking a more random but still short password (for example, just 8 random alphanumeric characters is log2(262+10)8 = ~48 bits), then the KDF becomes very attractive to help skyrocket the brute forcing cost to something more similar to trying to brute force the 256 bit key instead.