1

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?
  • 3
    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 5: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
  • 1
    I doubt the bottleneck of your application will be how you generate your CSRF tokens... – Lucas Kauffman Jun 11 '13 at 16:19
  • Of course not, the performance thing is simply a fact. – Fleshgrinder Jun 11 '13 at 22:33
  • I'll go for hash("sha1", uniqid() . mt_rand(0, mt_getrandmax())); which is fast as well. – Fleshgrinder Jun 11 '13 at 23:17
3

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.

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.