1

I need to hash 32 cryptographically random bytes, but later the verification the value with hash must be very fast, so I decided to use SHA256. Is it a security issue if my passwords are 32 cryptographically random bytes? Maybe you know some other fast and secure hashing algorithm?

2
  • g'day - as it stands this question is unclear - are you using the hash digest produced on host A as the password in a separate system B? or, are you just storing the sha2 hash digest to validate the password when the user returns? i know of a few slow and secure password hashing algorithms ,,, if your hash inputs are low-entropy, then the hash algorithm by itself won't add anything
    – brynk
    Commented Oct 8, 2022 at 19:39
  • I store the hash to validate the password when the client send request to my server. But the server response has to be fairly fast, which is why I am considering SHA256.
    – Szyszka947
    Commented Oct 8, 2022 at 20:48

3 Answers 3

2

If the server response only needs to be "fairly" fast, a relatively strong hash like bcrypt, scrypt, or Argon2i, tuned to match your expected performance, is still the preferred approach. The hash "work factors" should take as much processing time - and latency - as your application and users can tolerate. This is to maximize attack resistance.

But based solely on cracking vulnerability, for a truly random series of bytes of this size, there is no security issue. If an attacker is trying to crack the hash (recover the original bytes once they have possession of the hash), the total number of possibilities is 256^32 or ~1.15x10^77. Even if an attacker could try a quintillion guesses per second (far beyond current or mid-term future capability), they could not traverse even a tenth of this space in a thousand years. (Finding a collision for a given SHA256 might or might not be more likely, but still not a real-world concern.)

But since history of crypto is paved with good theories, I'd still go with a modern, strong hash. It's cheap insurance, primarily for things like unforeseen implementation side effects that reduce the attack space (for example, if someone discovered a weakness in your random-number generator).

1

If you have 256 bit long computer generated tokens used for authentication (generated using getrandom(2) or /dev/urandom), and you want to store sha256(token) in the database, that's fast and secure. You don't need a true password storage hash if your tokens are high-entropy. You don't need SHA-3 or Blake-3 or anything fancy, because the hash input is short. I believe the database lookup using the username to get the row with the hashed password will be slower than the "password" hash.

Don't forget to use a comparison function that is safe against timing attacks, so you definitely don't leak anything.

0
1

Requiring password hashing to be fast makes no sense to me. Usually passwords are hashed to prevent password disclosure in case the attacker gets access to the database. But hashes for this purpose are intentionally constructed to be relatively slow and to require relatively much memory. The examples of such password hashing algorithms are Argon2, PBKDF2, scrypt. You can adjust their parameters in such way, that the hashing time is acceptable to the users, e.g. 0.1 s. Then the attacker will be able to brute-force only 10 passwords per second, instead of 10 000 000 000 passwords per second for normal SHA256.

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .