Generating session CSRF token based on SSL session ID

Question

Following situation:

Application is only accessible via HTTPS/SPDY
nginx is sending the SSL session ID to the upstream server
Upon session start I'd like to use the first 128 characters of that string
In PHP: $csrf_token = substr($_SERVER["SSL_SESSION_ID"], 0, 128);
The CSRF token is stored on the server in the user’s session and a new token will be generated if a new session is generated

My question(s):

Is this approach secure (enough)?
- This question is regarding the usage of the SSL session ID and not related to the usage of session based CSRF tokens!
Would it be possible to use less characters (e.g. 32)?
Should I add some sort of secret salt to it?
Anything else that might be a problem with this?

I don't understand why you would make it so cumbersome to generate a token instead of using a crypto random. — Lucas Kauffman, Jun 11 '13 at 05:19
Why cumbersome? The session ID is there, it is extremely random, why not use it to save the time involved in generating a new hash? A string operation is lightning fast! — Fleshgrinder, Jun 11 '13 at 15:48
I doubt the bottleneck of your application will be how you generate your CSRF tokens... — Lucas Kauffman, Jun 11 '13 at 16:19
I'll go for `hash("sha1", uniqid() . mt_rand(0, mt_getrandmax()));` which is fast as well. — Fleshgrinder, Jun 11 '13 at 23:17

score 3 · Accepted Answer · answered Jun 11 '13 at 17:10

You can do this but the moment your app grows larger and needs ssl offloading it will break. Also take care about the length as you are exposing a part of the ssl session id which is responsible for protecting your CIA. If you would take a too large part of the Id or all of it and an attacker would be able to get it through xss, it could also break your ssl session.

Please don't be a dave.

score 2 · Answer 2 · edited Mar 17 '17 at 10:46

2

Re-purposing crypto datapoints for other purposes is one of the capital sins of data security.

There is no logical reason to do what you are suggesting. And whether or not a specific vulnerability for what you are suggesting is immediately available, it's still a bad idea.

Just use a random value, which is the known, vetted, accepted approach. Otherwise you stray into Dave territory.

edited Mar 17 '17 at 10:46

Community

1

answered Jun 11 '13 at 18:45

tylerl

82,665
26
149
230

Generating session CSRF token based on SSL session ID

2 Answers2