I think this misses the point: we should be doing everything we can to deprecate PBKDF2 because of the big differences between what a specialized attacker can do vs. the defender.<p>As a rough estimate: a $2k bitcoin miner can do 2^45 SHA-256 hashes/sec whereas your $2k laptop can do 2^16 hashes/sec; the attacker has ~a billion x advantage over you that can be multiplied based on their funding. At that point, doing even 10,000 PBKDF2 hashes may not make much of a difference.<p>argon2, scrypt and other memory hard password hashing algorithms reduce the orders of magnitude advantages of the attacker by requiring RAM. Attackers might be able to purchase RAM cheaper than the defender, but nothing close to a billion times cheaper.<p>Addressing concern #3 (want to have a password set on a laptop that decodes in a reasonable amount of time on a low-end smartphone), you could restrict the RAM to some small amount (like 256MB) if you anticipate needing to use a low-end device. This will still be a vast reduction in the attacker's advantage over PBKDF2.
My threat model isn't a directed attack, it's DB dumps with unhashed or unsalted passwords from random websites. I want to use a unique password on every site, and password managers provide a convenient way of doing that.<p>Even if every BW vault leaked, if it takes half a day to run through 8 a-zA-Z0-9, it's not practical to do that for every vault. On the other hand, if I'm being targeted, even increasing that to a month wouldn't really matter.<p>Every "critical" site I use also supports u2f 2fa, which I've turned on. So even if they got my passwords, there's the 2nd factor they don't have.<p>tl;dr: Just use a damn password manager, even one that has arguable issues such as this improves the average person's security by orders of magnitude.
If I understood correctly, the points are:<p>- using longer passwords (or salts) is better than increasing the number of rounds<p>- having the same database on different devices (top-CPU x older cellphone) have impacts on the performance for the user but not for the attacker (as a powerful hardware will be used)<p>Seems fair, for the average user. And the top user will prefer a longer password anyway.
A lot of the sub-threads seem to have decided to talk about using PBKDF2-SHA256 as a password hash like crypt(), which actually isn't what the linked report is about. PBKDF2, as its name suggests, is a key derivation function. We can use these as password hashes, and people do, but we can also use them to turn any human memorable password (like "stonks", "S&SMBMBbc&wem" or "fzg76@PRU385!") into a nice 128-bit or 256-bit symmetric encryption key and that's what they're doing in tools like Bitwarden or 1Password.<p>In this role, you very much have a practical option to just pick a decent password. "stonks" is not a good password, the second one is a Rhianna lyric ("... but chains and whips excite me") but the third one is a pretty obscure reference and it's neither likely that your adversary would "guess" it nor that the sort of brute force attacks envisioned would hit this random looking 13 character password.<p>Anyway, even as a password hash I've made the argument previously that stronger hashes only marginally improve things, far too many of your users will pick "stonks" or if you insist on eight characters maybe "stonks!!" and even if you have Argon2 tuned way up the attacker can reverse that because it's too obvious. If your users picked unique random passwords (as they might with tools like Bitwarden or 1Password, even though I personally use zx2c4's pass) then it doesn't matter if you use a terrible hash like some turn of the century PHP forum using MD5, because that's still safe with such passwords.
The model of hashing user plaintext passwords on server-side is itself a deeply flawed one. User password and master keys derived out of it should NEVER leave user-controlled computer. For authentication password-authenticated key agreement protocols [0] should be used, anything but it means that service does not treat user security as a high enough priority.<p>[0]: <a href="https://en.wikipedia.org/wiki/Password-authenticated_key_agreement" rel="nofollow">https://en.wikipedia.org/wiki/Password-authenticated_key_agr...</a>
User-defined passwords are a bad choice for an encryption KDF. I'm not disagreeing with sibling xxpor's tl;dr that worse is better here; getting everyone on password managers would be a huge net win for personal security. But debating the choice of KDF is missing the elephant in the room: that user passwords simply lack enough entropy for use as secure key material. It's like debating which kind of paper you should use to repair a huge hole in your bunker with a paper mache.<p>That said, asking the user to manually type full-size generated keys between devices is simply a nonstarter.<p>But what if the user stored their passwords in a private Matrix room? Matrix' solution to sharing encryption keys between devices is by being the communication channel by which users approve new devices from existing devices; upon approval the room's encryption key is sent to the new device encrypted using the new device's public key. That is, the room key can only ever be seen by the devices themselves. (I think this is a reasonable summary of encryption in Matrix, please correct me if I'm mistaken.) This is basically using a Matrix room as a general distributed, encrypted data store. Thoughts?
If it's not broke, don't fix it. The underlying hasher is most important anyway. Crappy passwords will always be susceptible to rainbow attacks.