Question

I’m interested in your advice/opinion on this security problem.

I was thinking on doing something like this:

1. Get hash MAC (sha256) from string built from userId + expirationTime and as secret key string built from some secret string and $_SERVER[‘HTTP_USER_AGENT’].
2. Get hash MAC (sha256) from userId + expirationTime and as secret key previously made hash (from step 1).
3. Build string from userId|expiration| and previously made hash (from step 2).
4. Encrypt given string (from step 3) with ‘rijndael-256’ algo. (mcrypt family of functions).
5. Encode to base64.
6. Set cookie with given value.

What do you think. Is this ok?
What else could I implement with $_SERVER[‘HTTP_USER_AGENT’] check, to make sure that the cookie isn’t stolen (except IP address)?

P.S. From sensitive data cookie would contain only userId.

EDIT:
Ok to clear some things.
I’m trying to make “safe” auth system that doesn’t rely on sessions. The app in question is build more or less as pure restful api.

Step 2:

Problem:
“Fu’s protocol does not provide an answer to this
question. There is only one key involved in Fu’s proto-
col, namely the server key. One straightforward solu-
tion is to use this server key to encrypt the data field
of every cookie; however, this solution is not secure.”

Solution:
“Our solution to this problem is simple and efficient.
We propose to use HMAC(user name|expiration time,
sk) as the encryption key. This solution has the fol-
lowing three good properties. First, the encryption key
is unique for each different cookie because of the user
name and expiration time. Note that whenever a new
cookie is created, a new expiration time is included in
the cookie. Second, the encryption key is unforgeable
because the server key is kept secret. Third, the encryp-
tion key of each cookie does not require any storage on
the server side or within the cookie, rather, it is com-
puted by a server dynamically.
”
From paper “A Secure Cookie Protocol” by Alex X. Liu1 , Jason M. Kovacs

Step 4:
Encrypts data (which would look something like this: ‘[e-mail]|34234324234|324erfkh42fx34gc4fgcc423g4’), so that even client couldn’t know exactly what’s inside.

Step 5:
Base64 encode is there just to make final value pretty.

Answer 1

I’ll bite.

In order to maintain any semblance of state you need to identify the user using a key of some type. That key is sent to the browser as a cookie OR through query string parameters.

Now, the validation of that key can occur inside the web server itself (session) or through checking some other storage mechanism, usually a database record.

The key itself should be obfuscated using some mechanism. The reason for the obfuscation is simply to make it harder to guess what values other keys might have if the originating user or someone else decides to inspect the value. For example, if the key is your user id (not recommended) and you are using incrementing ints then it’s trivial to guess the other user keys. I want to stress that obfuscating ( or even downright encrypting ) the key provides absolutely no protection against a hijacked session. ALL it does is make it harder to guess other peoples session keys.

That said, I believe the key should have nothing at all to do with your user id and instead be some other near random value like a generated GUID. Quite frankly a base 64 encoded GUID is at the exact same level of security as encrypting user id + time. It’s just that one is more computationally intensive on your server than the other.

Of course, this key could change upon each request. Browser posts something, you generate a new key and send it back. In the event the browser posts an out of date key then log it and kick them back to the login screen. This should prevent replay attacks .. to a degree. However, it introduces other challenges such as using the Back button on various browsers. So, you may not want to go down this path.

That said you can’t depend on the client IP address because the same user might send follow up requests using a different IP. You can’t depend on browser fingerprinting because any decent hacking tool will capture that and submit the same values regardless of whatever they are using.

Now, if you really want to do this right you should have SSL turned on. Otherwise you’re wasting your time. The entire conversation (from the login screen on) needs to be encrypted. If it’s not then someone could simply listen for that cookie, replay it immediately and hijack the session. Point is that they don’t need to know the values contained therein to use them. So all of that hashing, etc you have is just fluff that will increase your server load.

Did I say use SSL? 😉 This will encrypt the traffic from the beginning of the conversation and an attacker cannot replay the same packets as they would have to negotiate their own handshake with the server. Which means all you have to do is ensure that whatever session id you use is non-guessable so that one logged in user can’t take over another’s session.

---

So, to sum up: the method you posted is a waste of time.

You are much better off just getting a $10 SSL certificate and using a base 64 encoded GUID as the session ID. How you store that session info on your server doesn’t really matter… except in load balanced situations. At which point it needs to be out-of-process and backed by a database server.. but that’s another question.