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

2 Answers 2

Reset to default
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.

Improve this answer
0
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.

Improve this answer

You must log in to answer this question.

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