0

I want to create a server where after the user logs the server gives them a randomly generated access token that is hashed using SHA256, that I store in the database a long with an expiration date, I thought this was secure, until I remembered that the access token basically acts as a temporary password, which a hacker can access easily and brute force until they find a match. and I've heard that using SHA256 to store your passwords is bad because they are easily brute forceable.

also I don't like JWT because of the The limitations, its statless, and its encoded (I know it can be encrypted but still) I know tokens should not include sensitive info, but I think its better if we hide any details from hackers.

Thank you

Improve this question
1
  • Welcome to the community. You should use OIDC, introduce a challenge or similar. Your approach is easily replayable and the token can get stolen and reused. Also please look into JWS.
    – Sir Muffington
    Commented Jan 6 at 12:16

1 Answer 1

Reset to default
2

What you describe is a standard session ID. If the ID is sufficiently long (e.g., 128 bits) and generated with a secure random number generator, this scheme is perfectly fine. Note, however, that you must also protect the session ID in transit (with HTTPS) and client-side (e.g., by setting the appropriate cookie flags if the ID is stored in an HTTP cookie).

It's true that SHA-256 is unsuitable for password hashing, but this is because user-provided passwords are often poor and can indeed be attacked through brute-force. This does not apply to randomly generated, sufficiently long session IDs. Brute-forcing a random 128-bit ID is absolutely infeasible, so SHA-256 works perfectly fine here.

Improve this answer
4
  • If the session ID is sufficiently long and random the hashing can even be skipped at all
    – Steffen Ullrich
    Commented Jan 6 at 12:02
  • 1
    Hashing long-term session tokens (or similar secrets, e.g. refresh tokens or API keys) on the server is a good practice even if they're very long and fully random. Against remote attackers, it inherently prevents linear-time brute forcing via timing attack; against local-to-the-server (or the server's DB backups, etc.) attackers, it prevents hijacking user sessions via exposed secrets (one of the same reasons we hash passwords). Neither of those attacks are common, or always feasible, but there's a simple fix for both of them: a single round of a secure hash algorithm.
    – CBHacking
    Commented Jan 6 at 12:51
  • Excellent answer (+1). With respect to low-entropy passwords hashed with just a single round of unsalted SHA256 hashing - brute force may not even be necessary, as pre-computed rainbow tables already exist which contain the SHA256 hashes of many common passwords.
    – mti2935
    Commented Jan 6 at 14:42
  • Hashing the IDs mainly protects them from SQL injection attacks -- which are very common. If the IDs are simply stored as plaintext, an attacker may be able to dump all current session IDs with an SQL injection and use the IDs to temporarily take over the corresponding accounts. If only the hashes are stored, an attacker doesn't gain anything from obtaining them.
    – Ja1024
    Commented Jan 6 at 15:43

You must log in to answer this question.

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