8 ms·

On PBKDF2 iterations

62 points by rainworld 4y ago

jan_g 4y ago
Informative article! Regarding password length - it's been said many times that the easiest way to improve password security is to require longer passwords. 12 characters minimum, preferably 20. However, in practice, I've found out it's difficult to push through management/product people. It's completely fine to burden users with 10 different rules about upper/lower case, special symbols, etc., however requiring long passwords is out of the question. Would it not be much simpler to have one rule (for example, "Minimum length is 20 characters")?
- deleted 4y ago
  [deleted]
- dwaite 4y ago
  > Regarding password length - it's been said many times that the easiest way to improve password security is to require longer passwords. Often wrong. Longer passwords help with unlimited brute force attacks, but you can also do things like rate limit remote access (eg captchas after login failures) and use a more resource intensive key protection scheme like high iteration pbkdf2 or argon2
adrian_b 4y ago
It should be noted that PBKDF2 and similar key derivation algorithms are obsolete, precisely for the reason explained in this blog posting, that just doing a reasonable number of iterations of the key derivation function does not increase enough the difficulty of finding a weak password. PBKDF2 and similar key derivation algorithms are acceptable only when the key derivation must be run on some kind of microcontroller with limited resources, so the security requirements must be modest and it is understood that any really powerful adversary will be able to break the encryption, e.g. by using a large number of FPGAs or GPUs. Otherwise, a modern key derivation algorithm should be used, for instance Argon2, which also needs a very large amount of memory, in order to prevent fast parallel implementations of the key derivation function.
- silverlake 4y ago
  It’s not obsolete, the post is saying it is not magic. You need some number of bits to be secure in the next decade. PBKDF2(100k) gives you 16bits for free. For 80 bits the minimum password should have 64 bits, which is 5 Diceware words. Since most people have terrible passwords the extra 16 bits is not enough to reach an acceptable # of bits.
- deleted 4y ago
  [deleted]
- nmadden 4y ago
  So, Argon2 is great and everything, and in an economic security model it certainly is more secure than PBKDF2, given what we currently know about costs of operations. However, it doesn't really fundamentally change the argument of the article. Although the model is more complicated for Argon2, you'd still have to crank the parameters up to fairly insane levels to get the kind of security guarantees that are expected by modern cryptography. IMO, if you want secure long-term encryption then the only reliable choice is to use a high-entropy password/phrase/key in the first place. And if you do that, then the password on its own is resistant to brute force and so you don't need PBKDF2 or Argon2. (There is some "sweet spot" of hard-ish passwords of say 80 bits of entropy, where PBKDF2 or Argon2 would push it over into cryptographically-secure territory. But such a password is already extremely hard to remember, which means you are probably writing it down or storing it in a password manager already. So you may as well just make it longer).
  - KAMSPioneer 4y ago
    So a diceware-style passphrase of six random words is around 80 bits, and for 128 I would need about ten words in my passphrase, right? I tend to have a significantly easier time recalling a six-word passphrase than ten. So by your logic, key stretching makes sense in my case, am I following you correctly? Or is my math off? (I quite enjoyed your article, thanks!)
    - samastur 4y ago
matharmin 4y ago
The article has a good explanation to quantify the security that password hashing / PBKDF2 gives, but I disagree with the conclusion. 18 bits can make the difference between a password being trivial to crack, and practically impossible to crack with current technology. 128 bits is not some magic number that needs to be achieved to have strong security.
- nmadden 4y ago
  Would you be happy if a service you used encrypted your private data with 56-bit DES encryption? Because that is basically what you are saying. If a password is estimated to have 40 bits of entropy on average (as per Wikipedia), then adding 18 bits of protection takes it to 58 bits. Two decades ago we were able to crack DES keys in less than 24 hours: https://en.wikipedia.org/wiki/DES_Challenges https://en.wikipedia.org/wiki/DES_Challenges
  - dale_glass 4y ago
    It still helps if you're not actually using passwords. I use a Mooltipass (https://www.themooltipass.com/ https://www.themooltipass.com/) loaded with keys generated with pwgen -s 16 (fully random, alphanumeric, 16 chars) That seems to give about 95 bits per password, plus 18 brings it up to 113, which I think is not bad at all. I'm pretty sure I can count on my passwords not ever being cracked by brute force. Anybody stealing a password database will have time and effort constraints, and will likely be happy with just cracking the easier set. If a government wants my stuff it's much easier to just convince the service provider to give them the data directly.
    - nmadden 4y ago
      If you’re not actually remembering these passwords and you want to increase security from 95 to 113 bits, then it is much more efficient to simply add a few more characters to the password. pwgen -s 19 provides the same extra protection as 300,000+ iterations of PBKDF2.
nogridbag 4y ago
I recently switched to 1password instead of bitwarden precisely because 1password combines a long secret key along with your password to decrypt the vault. If im understanding the article correctly, it seems like that approach avoids the main pitfalls of using PBKDF2.
- sebk 4y ago
  Other than more convenient UX, with Bitwarden or any other password manager you can just generate an equivalently entropic "secret key" that you store in a file and that you manually concatenate with the password when unlocking your vault. The threat model that 1Password describes for its secret key is essentially the same as what you'd get handrolling it: https://1passwordstatic.com/files/security/1password-white-paper.pdf https://1passwordstatic.com/files/security/1password-white-p... (it should be assumed that an attacker who gains read access to the user’s disk will acquire the Secret Key) KeepassXC and derivatives also support Yubikey's proprietary hmac-challenge, wich generates the functional equivalent of the secret key off-OS, and FIDO2 devices with the hmac-secret extension provide that same functionally but with SHA256 instead of SHA1 for the HMAC. I don't know any mainstream password managers that support it yet.
- jonathanstrange 4y ago
  Attackers who can obtain the password database to crack it offline can also obtain the long secret, can't they?
  - nogridbag 4y ago
    Assuming there's an association that links my encrypted vault to my identity, they would have to break into my home and either find a printout of the secret key or much more likely simply steal phone and computer.
- the_mitsuhiko 4y ago
  I'm pretty sure 1password uses PBKDF2 to get to the decryption key of the vault.
ianpurton 4y ago
If you take it from the attacker perspective they won't generate all possible passwords to crack a password hash. They'll run through a dictionary of passwords in order of popularity trying each one. Services that rely on passwords to wrap private keys should check those passwords against known password breaches. i.e. https://haveibeenpwned.com/ https://haveibeenpwned.com/ with half a billion passwords. Then using a suitable hashing algorithm i.e. argon2id and a salt you get a high level of usability for the user and secured data.
- kevincox 4y ago
  It depends on what their goal is. If there is a database leak and they want to bulk-scam then yes, they probably will only try common passwords. But if it is a targeted attack they may be willing to spend white the resources brute-forcing the password of a high-value target.
eps 4y ago
Instead of requiring 12+ char passwords with special symbols and driving people mad, require a long passphrase. Everyone knows a verse from a song or a passage from a book and most people now have decent typing speed when it comes to text without $#^& and mixed case. So it's as fast to enter, much easier to recall and has a higher entropy even for phrases that aren't excessively long. The ballpark estimate of the entropy of English test is between 1.0 and 1.9 bits per character, e.g. see [0]. This means that even a short passphrase like this: And I thought passwords were the best option. would have between 40 and 80 bits of entropy. [0] https://www.sciencedirect.com/science/article/pii/0960077994900795 https://www.sciencedirect.com/science/article/pii/0960077994...
- deleted 4y ago
  [deleted]
- ayende 4y ago
  Except that then you have a list of common phrases that you can check. How many passpharses would be: "in god we trust" or "I love you". Figure out song titles and book titles, and you have a great list to check. See also: https://jbonneau.com/doc/BS12-USEC-passphrase_linguistics.pdf https://jbonneau.com/doc/BS12-USEC-passphrase_linguistics.pd...
  - eps 4y ago
    Clearly the minimum length restrition should still be there and be reasonably high, so none of these would qualify. Your "see also" is about "multiword passwords", which is not the same.
- zokier 4y ago
  You can not just look at a secret post-facto to reliabibly evaluate its strength, you have to include the process that was used to create the secret. And humans are notoriously bad at being RNGs, so anything chosen by a person is intrinsically weak as a secret.
- 8organicbits 4y ago
  My phones auto-complete shows how predictable English is. Lets start by guessing "And". I see predictions: lastly also I Let's pick "I". Next I see: will believe am If type "t" I get: think thought. Let's pick "thought" Next I see: I you it I'll help it out and enter passwords. Next I see: was would were Let's pick "were". Etc. A passphrase containing the word "password(s)" seems like an easy thing to guess especially given how popular "password" is as a password. Use of "thought" vs. "believe(d)" may just be my preference (curious if others see "thought" as a prediction). I suspect if you had a sample of my writing, you could learn my word preferences and prioritize words I regularly use. I'm seeing half the words in auto-complete's first three guesses. Most of the rest are synonyms of a top three guess. Only the word "passwords" broke that pattern. I wouldn't recommend such a predictable passphrase like that.
noodlesUK 4y ago
I agree with other commenters here. For a long time offline secret that needs to derive an encryption key, the solution is a longer passphrase. Diceware is fairly able to make passwords that are pretty strong. A 6 word Diceware with no additional complexity like separators or capitalisation is already 77 bits of entropy. 10 words is approx 128 bits.
bob1029 4y ago
The most familiar use of PBKDF2 for me is server-side hashing of client-supplied secrets wherein the hashed results are kept server-side and never revealed publicly. In this context of use, PBKDF2 is explicitly intended to slow down the server, not the [attacker/user]'s machine. Combine with heavy amounts of salt, and an attacker shouldn't be able to do much harm - even if the hashes are compromised. Are we saying PBKDF2 is used in other contexts and is less secure when used in these ways? Am I missing something?
- echoer_lyrist 4y ago
  It needs to be slow for attackers if the hash gets stolen like was the case with the LastPass breach.
- kreco 4y ago
  It looks strange to use "computational time" in order to slow down the server. In such scenario you are describing I believe an explicit delay like "thread_or_task.sleep()" would be even better? I believe that the "computational time" should be increased exactly for the "client-side" brute force. For example, if the attacker already have the password hash, the salt etc.
  - bob1029 4y ago
    I think I am seeing the light now. Assume the database is compromised. Does it really matter how many iterations if you are up against a nation state attacker? I agree with the article on this one. Assume the database cannot be compromised (i.e. my original case of simply defending the login form from brute force). Using any form of computationally-intensive hashing is a total waste of energy. I agree - Task.Delay(xxx), not arbitrary PBKDF2 iterations. Taking to the absolute extreme - does hashing even matter if you can hypothetically guarantee no inappropriate access? Taking the extremes for what they are, I might be inclined to look at storing passwords as simple salted SHA256 or worse. All of this password hardening crap is starting to sound like a half-hearted attempt to protect users from themselves and provides little value to site operators. Being able to tell the public "well at least we used a billion iterations of argon2" doesn't make the root cause of that whole situation sound much better.
rstuart4133 4y ago
From the article: > Either your password has sufficient entropy to resist brute-forcing, in which case it is already probably a cryptographic key, or it doesn’t – in which case it will eventually be cracked no matter how many iterations you apply to it. What a weird thing to say. The vast majority of passwords, probably even the majority of "password1234" passwords, won't be cracked. Whatever they are guarding are just not worth even the minor effort of checking "password1234". The corollary is most of the time you don't need 128 bit security. You just need enough security to make it not worth the effort. PBKDF2 does raise the bar on that effort by a few bits. That is is worthwhile, which seems to be the reverse of what he is saying. In the end 128 bits is not much more than a short cut. If you have less that 128 bits, you have to weigh up the value of the data you are protecting versus the effort of getting more entropy. But at 128 bits you can stop weighing up and just assume there will be a weaker link in the chain.
- aaron695 4y ago
  [dead]
gr2zr4 4y ago
I have a genuine question. Why every online password manager (lilke lastpass, 1 pass etc) uses PBKDF2 instead of Argon2id, scrypt, bcrypt, Lyra2?
- andrewmcwatters 4y ago
  One thought is that it is explicitly mentioned in NIST recommendations. If you were attempting formal compliance, that would be how to do it.
- dale_glass 4y ago
  I would guess: age, code availability, inertia, and lack of benefit. PBKDF2 is old, and had time to get adopted. Code is widely available for it, even included in many frameworks. Once you implemented something like this, unless it's really broken it's a lot of hassle to change it. I fairly recently looked into implementing password hashing, and my requirement was that somebody already did the job for me, because I'm not a pro cryptographer and don't trust myself to do it right. So since Qt supports PBKDF2, PBKDF2 it is. And Argon specifically is RAM hungry, which limits applications on things like low end virtual machines and mobile devices.
- voxic11 4y ago
  Lastpass and 1 pass launched before any of those existed except bcrypt. And I am guessing PBKDF2 was selected over bcrypt because its PBKDF2 just had more academic review.

62 points by rainworld 4y ago

Informative article! Regarding password length - it's been said many times that the easiest way to improve password security is to require longer passwords. 12 characters minimum, preferably 20. However, in practice, I've found out it's difficult to push through management/product people. It's completely fine to burden users with 10 different rules about upper/lower case, special symbols, etc., however requiring long passwords is out of the question. Would it not be much simpler to have one rule (for example, "Minimum length is 20 characters")?

deleted 4y ago
[deleted]
dwaite 4y ago
> Regarding password length - it's been said many times that the easiest way to improve password security is to require longer passwords. Often wrong. Longer passwords help with unlimited brute force attacks, but you can also do things like rate limit remote access (eg captchas after login failures) and use a more resource intensive key protection scheme like high iteration pbkdf2 or argon2

adrian_b 4y ago

It should be noted that PBKDF2 and similar key derivation algorithms are obsolete, precisely for the reason explained in this blog posting, that just doing a reasonable number of iterations of the key derivation function does not increase enough the difficulty of finding a weak password. PBKDF2 and similar key derivation algorithms are acceptable only when the key derivation must be run on some kind of microcontroller with limited resources, so the security requirements must be modest and it is understood that any really powerful adversary will be able to break the encryption, e.g. by using a large number of FPGAs or GPUs. Otherwise, a modern key derivation algorithm should be used, for instance Argon2, which also needs a very large amount of memory, in order to prevent fast parallel implementations of the key derivation function.

silverlake 4y ago
It’s not obsolete, the post is saying it is not magic. You need some number of bits to be secure in the next decade. PBKDF2(100k) gives you 16bits for free. For 80 bits the minimum password should have 64 bits, which is 5 Diceware words. Since most people have terrible passwords the extra 16 bits is not enough to reach an acceptable # of bits.
deleted 4y ago
[deleted]
nmadden 4y ago
So, Argon2 is great and everything, and in an economic security model it certainly is more secure than PBKDF2, given what we currently know about costs of operations. However, it doesn't really fundamentally change the argument of the article. Although the model is more complicated for Argon2, you'd still have to crank the parameters up to fairly insane levels to get the kind of security guarantees that are expected by modern cryptography. IMO, if you want secure long-term encryption then the only reliable choice is to use a high-entropy password/phrase/key in the first place. And if you do that, then the password on its own is resistant to brute force and so you don't need PBKDF2 or Argon2. (There is some "sweet spot" of hard-ish passwords of say 80 bits of entropy, where PBKDF2 or Argon2 would push it over into cryptographically-secure territory. But such a password is already extremely hard to remember, which means you are probably writing it down or storing it in a password manager already. So you may as well just make it longer).
- KAMSPioneer 4y ago
  So a diceware-style passphrase of six random words is around 80 bits, and for 128 I would need about ten words in my passphrase, right? I tend to have a significantly easier time recalling a six-word passphrase than ten. So by your logic, key stretching makes sense in my case, am I following you correctly? Or is my math off? (I quite enjoyed your article, thanks!)
  - samastur 4y ago

matharmin 4y ago

The article has a good explanation to quantify the security that password hashing / PBKDF2 gives, but I disagree with the conclusion. 18 bits can make the difference between a password being trivial to crack, and practically impossible to crack with current technology. 128 bits is not some magic number that needs to be achieved to have strong security.

nmadden 4y ago
Would you be happy if a service you used encrypted your private data with 56-bit DES encryption? Because that is basically what you are saying. If a password is estimated to have 40 bits of entropy on average (as per Wikipedia), then adding 18 bits of protection takes it to 58 bits. Two decades ago we were able to crack DES keys in less than 24 hours: https://en.wikipedia.org/wiki/DES_Challenges https://en.wikipedia.org/wiki/DES_Challenges
- dale_glass 4y ago
  It still helps if you're not actually using passwords. I use a Mooltipass (https://www.themooltipass.com/ https://www.themooltipass.com/) loaded with keys generated with pwgen -s 16 (fully random, alphanumeric, 16 chars) That seems to give about 95 bits per password, plus 18 brings it up to 113, which I think is not bad at all. I'm pretty sure I can count on my passwords not ever being cracked by brute force. Anybody stealing a password database will have time and effort constraints, and will likely be happy with just cracking the easier set. If a government wants my stuff it's much easier to just convince the service provider to give them the data directly.
  - nmadden 4y ago
    If you’re not actually remembering these passwords and you want to increase security from 95 to 113 bits, then it is much more efficient to simply add a few more characters to the password. pwgen -s 19 provides the same extra protection as 300,000+ iterations of PBKDF2.

nogridbag 4y ago

I recently switched to 1password instead of bitwarden precisely because 1password combines a long secret key along with your password to decrypt the vault. If im understanding the article correctly, it seems like that approach avoids the main pitfalls of using PBKDF2.

sebk 4y ago
Other than more convenient UX, with Bitwarden or any other password manager you can just generate an equivalently entropic "secret key" that you store in a file and that you manually concatenate with the password when unlocking your vault. The threat model that 1Password describes for its secret key is essentially the same as what you'd get handrolling it: https://1passwordstatic.com/files/security/1password-white-paper.pdf https://1passwordstatic.com/files/security/1password-white-p... (it should be assumed that an attacker who gains read access to the user’s disk will acquire the Secret Key) KeepassXC and derivatives also support Yubikey's proprietary hmac-challenge, wich generates the functional equivalent of the secret key off-OS, and FIDO2 devices with the hmac-secret extension provide that same functionally but with SHA256 instead of SHA1 for the HMAC. I don't know any mainstream password managers that support it yet.
jonathanstrange 4y ago
Attackers who can obtain the password database to crack it offline can also obtain the long secret, can't they?
- nogridbag 4y ago
  Assuming there's an association that links my encrypted vault to my identity, they would have to break into my home and either find a printout of the secret key or much more likely simply steal phone and computer.
the_mitsuhiko 4y ago
I'm pretty sure 1password uses PBKDF2 to get to the decryption key of the vault.

ianpurton 4y ago

If you take it from the attacker perspective they won't generate all possible passwords to crack a password hash. They'll run through a dictionary of passwords in order of popularity trying each one. Services that rely on passwords to wrap private keys should check those passwords against known password breaches. i.e. https://haveibeenpwned.com/ https://haveibeenpwned.com/ with half a billion passwords. Then using a suitable hashing algorithm i.e. argon2id and a salt you get a high level of usability for the user and secured data.

kevincox 4y ago
It depends on what their goal is. If there is a database leak and they want to bulk-scam then yes, they probably will only try common passwords. But if it is a targeted attack they may be willing to spend white the resources brute-forcing the password of a high-value target.

eps 4y ago

Instead of requiring 12+ char passwords with special symbols and driving people mad, require a long passphrase. Everyone knows a verse from a song or a passage from a book and most people now have decent typing speed when it comes to text without $#^& and mixed case. So it's as fast to enter, much easier to recall and has a higher entropy even for phrases that aren't excessively long. The ballpark estimate of the entropy of English test is between 1.0 and 1.9 bits per character, e.g. see [0]. This means that even a short passphrase like this: And I thought passwords were the best option. would have between 40 and 80 bits of entropy. [0] https://www.sciencedirect.com/science/article/pii/0960077994900795 https://www.sciencedirect.com/science/article/pii/0960077994...

deleted 4y ago
[deleted]
ayende 4y ago
Except that then you have a list of common phrases that you can check. How many passpharses would be: "in god we trust" or "I love you". Figure out song titles and book titles, and you have a great list to check. See also: https://jbonneau.com/doc/BS12-USEC-passphrase_linguistics.pdf https://jbonneau.com/doc/BS12-USEC-passphrase_linguistics.pd...
- eps 4y ago
  Clearly the minimum length restrition should still be there and be reasonably high, so none of these would qualify. Your "see also" is about "multiword passwords", which is not the same.
zokier 4y ago
You can not just look at a secret post-facto to reliabibly evaluate its strength, you have to include the process that was used to create the secret. And humans are notoriously bad at being RNGs, so anything chosen by a person is intrinsically weak as a secret.
8organicbits 4y ago
My phones auto-complete shows how predictable English is. Lets start by guessing "And". I see predictions: lastly also I Let's pick "I". Next I see: will believe am If type "t" I get: think thought. Let's pick "thought" Next I see: I you it I'll help it out and enter passwords. Next I see: was would were Let's pick "were". Etc. A passphrase containing the word "password(s)" seems like an easy thing to guess especially given how popular "password" is as a password. Use of "thought" vs. "believe(d)" may just be my preference (curious if others see "thought" as a prediction). I suspect if you had a sample of my writing, you could learn my word preferences and prioritize words I regularly use. I'm seeing half the words in auto-complete's first three guesses. Most of the rest are synonyms of a top three guess. Only the word "passwords" broke that pattern. I wouldn't recommend such a predictable passphrase like that.

noodlesUK 4y ago

I agree with other commenters here. For a long time offline secret that needs to derive an encryption key, the solution is a longer passphrase. Diceware is fairly able to make passwords that are pretty strong. A 6 word Diceware with no additional complexity like separators or capitalisation is already 77 bits of entropy. 10 words is approx 128 bits.

bob1029 4y ago

The most familiar use of PBKDF2 for me is server-side hashing of client-supplied secrets wherein the hashed results are kept server-side and never revealed publicly. In this context of use, PBKDF2 is explicitly intended to slow down the server, not the [attacker/user]'s machine. Combine with heavy amounts of salt, and an attacker shouldn't be able to do much harm - even if the hashes are compromised. Are we saying PBKDF2 is used in other contexts and is less secure when used in these ways? Am I missing something?

echoer_lyrist 4y ago
It needs to be slow for attackers if the hash gets stolen like was the case with the LastPass breach.
kreco 4y ago
It looks strange to use "computational time" in order to slow down the server. In such scenario you are describing I believe an explicit delay like "thread_or_task.sleep()" would be even better? I believe that the "computational time" should be increased exactly for the "client-side" brute force. For example, if the attacker already have the password hash, the salt etc.
- bob1029 4y ago
  I think I am seeing the light now. Assume the database is compromised. Does it really matter how many iterations if you are up against a nation state attacker? I agree with the article on this one. Assume the database cannot be compromised (i.e. my original case of simply defending the login form from brute force). Using any form of computationally-intensive hashing is a total waste of energy. I agree - Task.Delay(xxx), not arbitrary PBKDF2 iterations. Taking to the absolute extreme - does hashing even matter if you can hypothetically guarantee no inappropriate access? Taking the extremes for what they are, I might be inclined to look at storing passwords as simple salted SHA256 or worse. All of this password hardening crap is starting to sound like a half-hearted attempt to protect users from themselves and provides little value to site operators. Being able to tell the public "well at least we used a billion iterations of argon2" doesn't make the root cause of that whole situation sound much better.

rstuart4133 4y ago

From the article: > Either your password has sufficient entropy to resist brute-forcing, in which case it is already probably a cryptographic key, or it doesn’t – in which case it will eventually be cracked no matter how many iterations you apply to it. What a weird thing to say. The vast majority of passwords, probably even the majority of "password1234" passwords, won't be cracked. Whatever they are guarding are just not worth even the minor effort of checking "password1234". The corollary is most of the time you don't need 128 bit security. You just need enough security to make it not worth the effort. PBKDF2 does raise the bar on that effort by a few bits. That is is worthwhile, which seems to be the reverse of what he is saying. In the end 128 bits is not much more than a short cut. If you have less that 128 bits, you have to weigh up the value of the data you are protecting versus the effort of getting more entropy. But at 128 bits you can stop weighing up and just assume there will be a weaker link in the chain.

aaron695 4y ago
[dead]

gr2zr4 4y ago

I have a genuine question. Why every online password manager (lilke lastpass, 1 pass etc) uses PBKDF2 instead of Argon2id, scrypt, bcrypt, Lyra2?

andrewmcwatters 4y ago
One thought is that it is explicitly mentioned in NIST recommendations. If you were attempting formal compliance, that would be how to do it.
dale_glass 4y ago
I would guess: age, code availability, inertia, and lack of benefit. PBKDF2 is old, and had time to get adopted. Code is widely available for it, even included in many frameworks. Once you implemented something like this, unless it's really broken it's a lot of hassle to change it. I fairly recently looked into implementing password hashing, and my requirement was that somebody already did the job for me, because I'm not a pro cryptographer and don't trust myself to do it right. So since Qt supports PBKDF2, PBKDF2 it is. And Argon specifically is RAM hungry, which limits applications on things like low end virtual machines and mobile devices.
voxic11 4y ago
Lastpass and 1 pass launched before any of those existed except bcrypt. And I am guessing PBKDF2 was selected over bcrypt because its PBKDF2 just had more academic review.