4 ms·
> why would a password manager provide a configurable iteration count? Because end user devices vary a lot in speed.
by Tepix 4y ago
> why would a password manager provide a configurable iteration count?
Because end user devices vary a lot in speed.
- julian_sark 4y agoBenchmark it once on each device. Then have a user-friendly slider. "Do you want your security to be:" a) "It only secures pr0n from my aunt" (1s for fetching a password) b) "Not great, not terrible": (5s for fetching a password) c) "Pretty Good Protectivity": (10s for fetching a password) d) "The CIA haunts me and my name is Edward: (24 minutes for fetching a password)
- pilif 4y agoand even then there should be no way to offer a completely insecure iteration count to a user because one of their devices is slow because the attacker's devices won't be. Even on slow devices, password managers can employ techniques to help like only using the full count of rounds for a cold start but then re-encrypting the key for the vault key with fewer rounds but only keep that copy locally. That way a user of a very slow device only needs to wait for, say, 10s once on first unlock. While this is a downgrade in security, it's still better because now the key with the small amount of iterations is confined to the one device, not available on the server where an attacker can get bulk access. Of course, devices where 1M PBKDF2 iterations take so long that it's noticeable are probably also old enough to be full of unpatched (due to EOL) security holes which makes such devices the weakest link anyways, but this would still be a better situation because this way not all users are punished because of one user's slow device.