# Hashing a random string of letters upper/lower + numbers 256 characters long with SHA256

Is hashing a pseudo-random generated string of letters upper/lower + numbers 256 characters long with SHA256 insecure, in the sense that in any reasonable amount of time you can go from hash to original string?

Would using a more conventionally strong password hashing algorithm be necessary to still answer no to the above question?

• How long is the string? Do you mean "random" as in "random password" or like "random generated by a pseudo random generator"? Commented Jan 16, 2023 at 14:44
• Random as in pseudo random generator Commented Jan 17, 2023 at 19:53

SHA-256 is considered to be resistant to preimage attacks. There is no analytical way to compute what string you have hashed. The only way to find i out is brute-forcing.

You say, you use upper and lower case letters and digits. Assuming you use English, this means 62 characters: 26 lower case, 26 upper case, 10 digits. The number of all possible strings is $$62^{256} = 2^{1524}$$. It is impossible to try all of them, even if the attacker uses the computing power of the whole world and has millions years of time.

Would using a more conventionally strong password hashing algorithm be necessary to still answer no to the above question?

SHA-256 is designed to be very fast. To prevent brute-forcing, algorithm needs to be relatively resoutce-intensive, i.e. it should be slow and, when possible, require much memory to prevent optimization of brute-forcing. You can take Argon2, scrypt or any other modern password-stretching (password-derivation) algorithm. With proper parameters you can reach resistance to brute-forcing even for essentially shorter passwords, like around 15 random characters long.

Here are some conditions when brute-forcing can make sence for the attacker:

• Passwords are generated automatically, but the PRNG has low entropy.
• Passwords are created by humans.
• There are many users in the system. Salt is not used. Using rainbow tables can give an advantage.

Some mining devices like S19 can compute 10^14 hashes per second. This is about 10^20 in 15 days, or about 2^66. This is just a single device. That's why resource intensive password derivation may well make sense even for short validity period like 15 days. With 1 000 000 users the chances to brute-force a password for at least one of them are even higher.

If performance is important to you, then just configure the hashing algorithm properly, e.g. set parameters for Argon2, PBKDF2, bcrypt, scrypt or other so that the computation takes 0.1s. Then instead of 2^66 hashes such device will be able to test only 10^3 hashes per second, or 10^9 hashes in 15 days, or 2^30. This is essentially less than 2^66.

TLDR: Use resource intensive password hashing algorithms. They use salt and prevent rainbow tables. Configure their parameters to get the performance you need.

• If each password/secret is 256 chars (minimum) alpha LC + UC and numbers, do I still have to worry about brute forcing with sha256 has alone? I 100% agree and understand the purpose behind what you're saying, but I actually need the speed in this case, and increased the "pw" length to prevent brute forcing. I know how that sounds, but I would think a pw this large prevents brute forcing astronomically more than adding 500ms to the hashing (for small pws) - or at least close to equally in some ways - terms or reasonably brute forcing. Commented Jan 17, 2023 at 19:15
• Also, does this still apply if I increase to 512 chars? Passwords also expire every 15 days. So would they have enough time to brute force within a max of 15 days depending on when they got a hold of a stolen password hash. Commented Jan 17, 2023 at 19:21
• The application will only keep a hash. This means, an attacker does not need to find the real password, but just any other string that produces the same hash. And the success in such case depends not on the password length, but on how many password the attacker can test per second. The faster the hashing, the faster can the attacker find a string that produces the same hash. Hashing of 256 bytes is slower than 32 bytes not "astronomically" as you say, but linearly, just about 8 time slower. 512 bytes just 16 times slower. Commented Jan 17, 2023 at 20:32
• I accidentally deleted my original comment. Is it really linear? 2^32 / 2^16 is over 65K? And would it really be possible to find a collision with that large of an input? Trying to do the math :/ Commented Jan 17, 2023 at 22:28
• Ah, you're saying time to hash, not number of hashes is linear. Yes, but even so, the passwords expire every 15 days. So if we take the fastest hardware known to be available for sha256 hashing, what is the average time to crack a password/find something that hashes the same, that is equal to 512 characters, same as before, using brute force, or even rainbow tables? Commented Jan 17, 2023 at 22:31