How do high hash rates affect hashed password security? Given the increase in hash rate since the rise of numerous block chains, I wonder how this affects the security of many hashed password systems.

Is a standard linux /etc/shadow file still regarded safe or does it somehow need to be updated with another algorithm or bigger salt or in some other way?
Are hashed passwords using hmac with sha256 safe given a 20 character long secret key? Can someone give some rough calculations to give an idea how long it takes to find a password?
Is it advisable to use hmac with a slower algorithm like bcrypt, scrypt or PBKDF2?

By &quot;safe&quot; I mean can modern hardware like ASIC reproduce a given hash in a reasonable amount of time. Some background context to my question. User input will be one way encrypted (hmac sha256) stored in a database. Suppose the database is hacked, how hard is it for an attacker to find original user input. If it turns out this type of encryption is too easy for asic machines, should I switch to some other one way encryption like bcrypt or pbkdf2?
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.