Do I need to salt the hash of a long random session key in the DB?

Question

Information Security

If the session key is random and has a length of 256 bits (or more), then neither the rainbow table nor the brute force hash (which, of course, should also have no less length) seem real, so I assume that it is enough to simply store the hash from the session key . Is this true, or is salt better? What possible vulnerabilities have I not considered? About the fact that SQL injection is not the only way to intercept a session, I know there are at least XSS and phishing, but I am now considering a scenario of stealing a database.

Answer 1

I don’t know what is not taken into account, but the presence of salt will allow you to invalidate all session keys very quickly.
I'd rather add some salt at the very least for those considerations.

Answer 2

session key is a temporary key for 2 weeks, which is randomly generated and does not depend on the user's password in any way. so you? if yes, then why is there something to invalidate and salt?

Answer 3

Why salt randomly? Salt is needed for randomization of obviously non-random values, its presence provides protection against the selection of the initial value by hash through random tables by increasing the search area as a power of length. And if the source is already long and random, you can’t pick it up anyway. Not necessary.

Answer 4

Why salt hashes at all? Against database leaks: if hashes are gone, it is difficult to recover passwords from them.
• If, if a leak is suspected, we can regenerate the keys or declare them expired;
• If the keys are kept anywhere, but not in the database;
• If the keys are so long and random that it would be difficult to reverse the algorithm by combined hacker forces
, then why?
However, do not forget that by hashing, you automatically reduce the cryptographic strength of your algorithm to the hash length. Or maybe it's easier to initially make keys of this length?