0
$\begingroup$

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.

  1. 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?
  2. 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?
  3. Is it advisable to use hmac with a slower algorithm like bcrypt, scrypt or PBKDF2?

By "safe" 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?

Improve this question
$\endgroup$
6
  • 1
    $\begingroup$ HMAC is not a password hashing algorithm. It is a keyed hash function. Passwords are used with good password hashing algorithms that are memory-hard and thread and iteration-based protection against the password cracking methods, ASIC or not. See Argon2. This question is not clear about what are you trying to achieve. Use Argon2id and adjust the iteration according to your needs. $\endgroup$
    – kelalaka
    Feb 18, 2021 at 15:39
  • 1
    $\begingroup$ Password hashing requires unique salt per password that eliminates the rainbow tables and decreased the power of any adversary to batch attacks. The iteration increases the cost of the attacker and the defender, too. Thread-based protection eliminates the parallelization, too. $\endgroup$
    – kelalaka
    Feb 18, 2021 at 15:41
  • $\begingroup$ I have added some background information to my question hope it's more clear now. $\endgroup$
    – rob
    Feb 18, 2021 at 19:49
  • $\begingroup$ How to securely hash passwords? $\endgroup$
    – kelalaka
    Feb 18, 2021 at 19:52
  • 1
    $\begingroup$ updated 2020 : security.stackexchange.com/a/3700/86735 $\endgroup$
    – kelalaka
    Feb 18, 2021 at 20:02

1 Answer 1

Reset to default
2
$\begingroup$

  1. Linux uses "sha512crypt", which isn't memory-hard but is fine given a moderately strong input passphrase.

  2. 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. "Character" 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.

  3. 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.

Improve this answer
$\endgroup$
6
  • $\begingroup$ 1. Does that mean that a 20 letter password is strong enough? And do I understand correctly that block chain mining power (hash rates) do not form a threat to this algorithm? (maybe a noob question but I'm trying to get a clean understanding) 2. I meant 20 ascii charachters so 20 bytes. 3. I see, thanks for pointing this out. $\endgroup$
    – rob
    Feb 18, 2021 at 19:54
  • $\begingroup$ Use the word list method. Use a passphrase. If you need a shorter password, generate it using your password manager's generation system. 20 ASCII characters will be fine IF SAFELY GENERATED VIA A PASSWORD MANAGER OR SIMILAR RANDOM SYSTEM. Otherwise no password will be safe. $\endgroup$
    – SAI Peregrinus
    Feb 18, 2021 at 21:16
  • $\begingroup$ Blockchain mining power is largely focused on the double-sha256 of Bitcoin. Mining power for other algorithms is much lower. The algorithm Linux uses (even when in sha256crypt mode) will usually be configured to run several thousand iterations of its hash, rather than 2. A memory-hard or cache-hard algorithm would be better, but Linux logins should be fine in most cases. $\endgroup$
    – SAI Peregrinus
    Feb 18, 2021 at 21:18
  • 1
    $\begingroup$ Some nitpicks, HMAC ... uses a uniformly-random secret key, it requires uniformly-random secret key. If that's impossible, use bcrypt, you skipped scrypt. $\endgroup$
    – kelalaka
    Feb 19, 2021 at 16:17
  • 1
    $\begingroup$ scrypt is based on PBKDF2 so in theory there might be systems out there that have PBKDF2 and scrypt but not bcrypt. I'll be danged if I'm going to search for one though. $\endgroup$
    – Maarten Bodewes ♦
    Feb 21, 2021 at 2:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.