Argon2 iteration count seems too low

Ask the Community Password Manager
,
1

I was just now updating some security stuff in bitwarden, and I wanted to change to argon2 kdf, however the iteration count seems way too low. The current max count is 10, which results in very fast execution times.

Using the maximum reasonable settings results in less than 200ms, which is potentially not very secure. Ideally, I would like the execution time to take at least 1 second on my fastest device, and less than 5 seconds on my slowest device.

$ echo testpass | argon2 testsalt -id -t 10 -m 15 -p 2
Type:		Argon2id
Iterations:	10
Memory:		32768 KiB
Parallelism:	2
Hash:		760af24571bbcd6644820bb12094828f9953acd0133e358cb94c068f743228dc
Encoded:	$argon2id$v=19$m=32768,t=10,p=2$dGVzdHNhbHQ$dgryRXG7zWZEgguxIJSCj5lTrNATPjWMuUwGj3QyKNw
0.124 seconds
Verification ok

I understand there needs to be a limit to protect users from themselves, but 10 is way too low and is leaving at least 800ms of additional margin on the table in my specific case.

2

Reduce parallelism, increase memory.

3

Please see this post for why I can’t raise the memory consumption.

Using slightly better settings is an improvement, but this isn’t really a good result. Using 64M is probably okay, but going much higher could result in failing to unlock the vault according to various posts.

The ideal situation would be to just allow more iterations. It’s a simple fix to this specific problem.

$ echo testpass | argon2 testsalt -id -t 10 -m 16 -p 1
Type:		Argon2id
Iterations:	10
Memory:		65536 KiB
Parallelism:	1
Hash:		12ce6c066079f7dc48069837416383c5e2397dd402fed59ec5edb2eafbc6d3c2
Encoded:	$argon2id$v=19$m=65536,t=10,p=1$dGVzdHNhbHQ$Es5sBmB599xIBpg3QWODxeI5fdQC/tWexe2y6vvG08I
0.384 seconds
Verification ok
4

Are you able to use biometric unlock when autofilling on your iPhone?

1 Like
5

Thanks, that might actually fix my problem, I’ll have to play around with it. I might have misread when they were talking about alternate unlocking mechanisms.

I still think 10 is probably too low of a limit, especially in memory constrained environments, the devs should probably take a look at that.

1 Like
6

Feel free to post a Feature Request.

7

In the initial PR, the max iterations were 1024. This lead to QA soft-locking (>30 min unlock time) themselves out of their account. I feel like there could be a slightly better balance, but some users will always max out the settings, even if it’s not reasonable in their case.

Besides that, half a second of argon2 is still orders of magnitude above most PBKDF2 settings that take multiple seconds, when it comes to cracking resistance. Unless your master-password is exceptionally weak, this setting is secure (as in, will take a motivated attacker too many resources, both time and computational cost wise to make it worth it to crack your account, if they had obtained an encrypted copy).

1 Like
8

I don’t disagree with anything you said, but I would like to reiterate that if I am willing to wait 1-5 seconds while my device spins, I am leaving some security on the table if it takes less than that. 1024 is probably too high, but a limit of 50-100 is much more reasonable.

I agree that argon2 is probably enough with 500ms, but systems should not be designed to only be secure against attacks today. There should be extra margin anywhere it makes sense to keep pace with improvements in computing and cryptanalysis.