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.
