Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

As title says I'm trying to implement a secure cookie protocol

HMAC(username|expiration name|data|session key, sk)

It seams that session key is not constant during whole application session lifetime. Now I'm not sure what to replace it with, someone suggested to me to use browser agent but it doesn't seem unique or too hard to produce, anyone has any suggestion?

I also wonder where should I store server key. (Hard code it into source code, or there is a batter solution?)

share|improve this question
I've seen this paper before. Do not use it. It's crap. It's eight years old and was written by some second-year post docs from Texas. Honestly. – John Wu Nov 22 '13 at 1:26
@JohnWu can you provide any sources supporting the claim that "It's crap"? Its age doesn't make it wrong and you don't have to have a PhD to write a good protocol. I'm very interested to find a newer/better/more authoritative resource if it exists. – Brandon Cook May 10 '14 at 18:29
It's age DOES make it wrong because on the internet technology changes rapidly. Eight years ago IE6 was industry standard-- laughable today. Meanwhile, new W3C standards have been added (such as HttpOnly cookies) which make this protocol obsolete. Implement it if you want to. I'm telling you it's a waste of time. – John Wu Jun 5 '14 at 14:28
If you are looking for a "source supporting the claim it is crap" I suggest you email the authors and ask them if they believe this paper is up to date. Please post their response. – John Wu Jun 5 '14 at 14:32
up vote 3 down vote accepted

This session implementation does nothing to address OWASP a9. In short its vulnerable to a replay attack. So if a hacker is sniffing the network or has an XSS vulnerability in your site then they can just copy this value and use it.

You should use as little cryptography as possible. Cryptography is hard, it adds complexity and when it fails it can be disastrous.

A cookie should be a large cryptographic nonce, and reference server side state. You should transmit this cryptographic nonce as a cookie with all of the security flags enabled (httponly, Secure, and scope).

On a side note, Amazon AWS's RESTful authentication is not bad.

share|improve this answer
So you suggest to just generate random value, use it as a key to userID, and on each request get userID from server, thought if this is vulnerable to replay attack (and it seems to me it is) isnt secure cookie protocol batter approach as I dont need to store data on server which makes application a lot faster. – F.T Sep 20 '12 at 0:21
@F.T Yes, its is vulnerable to a reply attack. Thats why the Secure and HTTPOnly flags are set. So that the cookie cannot be leaked with XSS or over the wire. Transmitting your session state in every HTTP request eats up your clients bandwidth. A memcachd session store on the same LAN is very fast. – rook Sep 20 '12 at 0:25

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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