How do high hash rates affect hashed password security?
Linux uses &quot;sha512crypt&quot;, which isn't memory-hard but is fine given a moderately strong input passphrase.

HMAC-SHA256 isn't a password-hashing algorithm. It's not even a hash function. It requires a uniformly-random secret key which it uses on a message to produce a Message Authentication Code (tag) of that message under that key. The password-based key derivation function PBKDF2 uses HMAC internally to create a KDF, which can also be used as a password-hashing function. The rest of this question is impossible to answer: a 20-character long secret key just doesn't define much. &quot;Character&quot; isn't well-defined. 16 bytes, chosen uniformly at random (ie 128 bits) will be secure as the key for HMAC-SHA256. No password is used in such a system, since HMAC doesn't take a password.

This question is nonsense. It's impossible to use HMAC with PBKDF2, since PBKDF2 uses HMAC. Likewise bcrypt isn't a cryptographic hash function and therefore violates some of the assumptions used in HMAC's security proofs.


Use Argon2id for your password hashing function if possible. If that's impossible, use bcrypt. If that's impossible, use PBKDF2-HMAC-SHA256 (I doubt you've got scrypt in that case).
Use the EFF Long Word List and 5 good-quality dice, and pick a passphrase long enough for your desired security. Each word is just over 13 bits of entropy, so 7 words is 91 bits (safe for the next few decades), 10 words is 130 bits (definitely safe for the next few million years unless the attacker has a really big quantum computer), 20 words is 260 bits (safe even against planet-sized quantum computers for a few million years). If you're using 10 words or more, password-hashing function choice doesn't really matter much.