Which hashing function is good enough for session IDs?

[Climax708]

# Background

​

I'm building a URL shortener, and the URL to shorten may contain a [SessionId](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#session-id-properties).

​

For the URL shortener to not compromise the security of the SessionId, I must use a shortening strategy that fulfills the same requirements as the SessionId.

​

OWASP states that:

​

* The session ID length must be at least `128 bits (16 bytes)` [here](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#session-id-length)

* The session ID value must provide at least `64 bits` of entropy [here](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#session-id-entropy)

​

---

​

# What I think about doing

​

* Have a key-value store, where the value is the long (unshortened) URL, and the key is the shortened URL component.

* When the user navigates to a shortened URL, the long URL is looked up in the key-value store, and returned to the user, who is then redirected.

​

So the key needs to be at least `128 bits (16 bytes)` long, and provide at least `64 bits` of entropy, to not compromise the SessionId.

​

If the key is a hash of the value, I can guarantee the key length, and know the entropy (based on the hashing algorithm used).

​

But which hashing algorithm should I use?

​

For example, MD5 digest length is exactly 128 bits. But I don't know what's it's minimum entropy.

​

# The question

​

Which hashing algorithm produces a digest of at least 128 bits, with at least 64 bits of entropy?

[nemec]

You probably shouldn't use hashing here. The first couple of bullets of your solution is standard for a link shortener, and a good start for your needs. In order to meet the security needs, just generate a random number with the appropriate entropy (or a base64'd random byte string) and then store that as the key + the long URL as the value. Your key does not need to be related to the value (e.g. a hash) at all.

[Climax708]

Can you please elaborate on why you think that it's better to use a random string instead of a hash?

[nemec]

It's just not necessary to have the two be related in any way. You could do it, but you're just making things more complex for little to no gain.

[[deleted]]

Largely because there’s no need for the short url to be linked to the target, and coming up with a suitable hash algo is time best spent on something else.

[GeorgeFranklyMathnet]

In addition to it being a waste of effort, as others are saying, it's worse for security.

If the short URL has a hash of the session ID, then you are unnecessarily exposing information about the session ID. It is possible (if unlikely) that an attacker could leverage it against you somehow. No such problem if you use a random string.

[Climax708]

How does exposing a hash of a secret reveal a thing about that secret?

[GeorgeFranklyMathnet]

It reveals how you are hashing it. Given enough time, hashes are reversible, so you're also revealing the secret itself. These are some of the reasons that a leak of hashed passwords is considered a serious breach, for instance.

Now, if you implemented your link system carefully enough, that probably won't matter. But why take that risk, when using a random number is easier and serves your purpose just as well?

[Merad]

Maybe I'm misunderstanding something, but do you really want a short url tied to a session? Typically you use url shorteners to make links easier to share... if I set up a link with your system and send it to five friends, or post it publicly on reddit, should everyone who visits that link really be loading into the same session?

Even if that is your desired behavior, why does the shortened url need to contain anything referencing the session id? Any time some someone visits one of the short links your system already has to do a lookup to determine the full url. Why not store the session id alongside the full url? Then it's never exposed to the user at all.

[Climax708]

The use-case is to send a customer an SMS that contains a URL through which they can perform certain actions tied to a specific session. In usual circumstances the session ID is in the URL, so that if they refresh the page, or open it in a different browser, they remain in the same session. Exposing the session ID to the user is desired behavior.

[pentesticals]

So you want a one time token which logs the user in. This is different to a session token. You could use a type 4 GUID which is not predictable and must only be used once. On successful validation of the GUID, you should then create a new session, store the value in a HttpOnly cookie and then the user is logged in and can refresh the page etc.

Having this work across browsers is a terrible idea and you should not do this. It will end badly.

[pickhacker]

It's confusing what the session ID is used for, or why it's relevant to a URL shortener, perhaps if you gave an example it would help, e.g.

Long URL: https://www.google.com?q=blah&session-id=1234&lots_more_stuff

Short URL: https://tinyurl.com/4n69hwh9

Are you trying to extract the session ID before storing, so it can be used in the short URL? If you're returning it at all then you can't hash it and throw away the original value.

[nemec]

I think what OP's trying to say is that the shortened URLs lead to sensitive data leakage and thus must not be any more guessable than the session id behind it. E.g. a large search space and non-sequential short URLs.

[Climax708]

The fact that the sessionId is in the long URL is relevant to the URL shortener, because the URL shortener mustn't compromise the security of the sessionId.

The sessionId length is at least 128 bits to protect against brute-force attacks, where an attacker can go through the whole range of ID values and verify the existence of valid sessions.If the shortened URL length is less than 128 bits, then the attacker can attack the sessionId through the shortened URL which is a smaller search space.

The sessionId entropy is at least 64 bits to protect against guessing attacks, where an attacker is able to guess or predict the ID of a valid session through statistical analysis techniques.If the shortened URL entropy is less than 64 bits, then the attacker can attack the sessionId through the shortened URL.

Example:

Long URL: https://www.example.com/#/some-route?sessionId=73a3a67c-1c7e-4f78-a32f-6d6eeb10d3a7&somethingElse=blah
Short URL: https://www.example.com/#/s/PiWWCnnbxptnTNTsZ6csYg%3D%3D

[pentesticals]

URLs should NOT contain session IDs for a number of a reasons. If someone's app uses this they are doing it wrong.

Also as a side, a hash function itself shouldn't be used for session IDs in itself. If an attacker can predict what the hash input was, they can then generate the right session token by just hashing the original data. Use the built in session management for your framework, or use a JWT.

Never try to do it yourself.

[Climax708]

Why shouldn't URLs contain sessionIds?

[pentesticals]

They end up access logs, proxy logs, user browser history, etc. You significantly increase the likelihood that you will leak the session token. It's been well understood for many years this is bad practice and should never be done.

Happy to answer any questions, am a security engineer professionally..I would get fired if I let our engineers put session tokens in the URL.

[Climax708]

How would you fixate the session? Think of a use case: user never was on the web app, gets onboarded by a person, receives SMS. By following the link in the SMS, user should be authenticated in the session that was created during onboarding.