Can we benefit from hashing CSPRNG outputs for session identifiers?

Recently I was digging into session management, and it appears to be a best practice to assign a session identifier to a hashed CSPRNG output.

session_identifier = hash(algorithm, CSPRNG(number_of_bits))

Why is this a good idea?

In one of the answers here, they said:

If we generate strong random session ids, do we still need the hash? Absolutely!

PHP’s native session management system takes this approach as well.


Hash functions are one-way, so theoretically it’s not possible to get the CSPRNG output. Which means … we can’t predict further CSPRNG outputs if we don’t even have one, right? (Assuming the attacker/observer doesn’t have access to the server where the CSPRNGs live.)

This is beginning to make sense. Perhaps one of the reasons they’re doing it is because systems might fall back to insecure CSPRNGs/RNGs.

But anyways, what are your guys’ thoughts? I’m new to cryptography, so I could be wrong about so many things.

Hashing a CSPRNG helps in nullifying a possible askew from midpoint, but your weakest spot will be far before that.

@crypto Could you please clarify what you mean by “askew from midpoint”?

Midpoint meaning, nullifying any tilt to either side. Think of it as trying to accomplish 50/50. You want to rid the output from anything that isn’t that. With a hash there is no (or should not be any) inclination. That’s what the hash is useful for.

1 Like

That makes more sense now, thank you!

1 Like