The first two are good enough, but shouldn't be the only protection. In general salts (adding an per password random string to the raw password) and pepper(addding an random string that is shared across the application) should be added.
Pbkdf2 is quite old and has an attack vector from ASICs and FPGA, but is still quite widespread for applications and protocols.
Honestly, throw a dart. I think the right way to think about PBKDF2 vs. Argon2[†] is that Argon2 reaches better levels of security with less cost to "real users" (ie, genuine login attempt latency). It would be a little weird to deliberately select PBKDF2 for a new application today? It would not be among your top 5 security concerns though.
[†] Really, "PBKDF2 vs. any modern password hash".
'tptacek has written about this earlier on HN. See https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
For comparison, see also the section named Password handling in Cryptographic Right Answers: Post Quantum Edition https://www.latacora.com/blog/2024/07/29/crypto-right-answer...
The first two are good enough, but shouldn't be the only protection. In general salts (adding an per password random string to the raw password) and pepper(addding an random string that is shared across the application) should be added.
Pbkdf2 is quite old and has an attack vector from ASICs and FPGA, but is still quite widespread for applications and protocols.
Of those, scrypt or argon2id. PBKDF2 is for FIPS compliance.
Honestly, throw a dart. I think the right way to think about PBKDF2 vs. Argon2[†] is that Argon2 reaches better levels of security with less cost to "real users" (ie, genuine login attempt latency). It would be a little weird to deliberately select PBKDF2 for a new application today? It would not be among your top 5 security concerns though.
[†] Really, "PBKDF2 vs. any modern password hash".