Encrypted cookie (MAC) - industry standard?

Posted on 2004-08-24
Medium Priority
Last Modified: 2010-04-11
We are implementing a single signon solution that involves storing an encrypted cookie with the user's username as an access token.

2 Questions:

1. We'd like to make sure the cookie can't be used in a replay attack & so plan to include the IP address in it, along with an expiration time and a "MAC" (message authentication check) code to make sure the cookie wasn't tampered with.

We've seen the article at: http://www.w3.org/Security/Faq/CLT-Q10, which explains what's in a MAC (MAC = MD5("secret key " +
           MD5("session ID" + "issue date" +
               "expiration time" + "IP address" +
               "secret key")

The question is, is that the industry standard for a MAC? Is there an industry standard for MAC's at all?

2. What encryption algorithm is recommended for the cookie? Triple-DES? MD5? On what basis should one decide on an encryption algorithm?

Question by:equaad
  • 6

Accepted Solution

ErikPhilips earned 1500 total points
ID: 11897408
First off, adding the IP address prevents people on dialup or people on DHCP Cable modems and DSL from possibly using the cookie.  As long as thats ok you're good to go.

Secondly, I would suggest 3 things.
1.  buy this book:
(not nessesarily from amazon, just where I bought it from)

2. SHA would probably be the best hash function for your MAC.

3. You don't need to decrypt the message, you only need to encrypt the message on your side and compare the Hashs.

For example, your server has the "secret" key.  When you create a one way hash, and give it to a client, you only need to compare the has the client has to the hash you have.

More relavant to your implementation, I would create a table in a database with Hashkey, SessionID, Issue Date, Expiration Time, Ip Address, Secret Key.  And only give the client the hashkey. You can lookup all the hash keys that exist in the database and get the relavant information.  (the SHA hash is a 160bit value.  You may have to store the hash as text, as the hashes are huge)


If you really want to actually store that information on the client, I would suggest using blowfish for your encryption.

Expert Comment

ID: 11897456
In reference to "Is there an industry standard for MAC's at all?" I don't believe there is a standard that the "industry" always uses, but both MD5 and SHA are highly recommended.  SHA highly over MD5 for security reasons (I don't have my book here at work).

(ps when I use the word hash above, its always a one way hash, which can not be used to recreate the informaiton the hash was created from.)

Expert Comment

ID: 11897462
3. You don't need to decrypt the message, you only need to encrypt the message on your side and compare the Hashs.

was suppose to say

3. You don't need to decrypt the message, you only need to hash the message on your side and compare the Hashs.

(message being the information unique to this client)
KuppingerCole Reviews AlgoSec in Executive Report

Leading analyst firm, KuppingerCole reviews AlgoSec's Security Policy Management Solution, and the security challenges faced by companies today in their Executive View report.


Author Comment

ID: 11904807
Hi Erik, thanks for your answers. Couple of clarifications:

- in further reading I've come across something called HMAC which looks like it might be an industry standard for MAC codes. Is this your understanding also or is HMAC used for something else? See rfc: http://www.faqs.org/rfcs/rfc2104.html

- Sounds like you're recommending just using a hash for the whole cookie instead of using a hash for the MAC and encryption for the cookie. Can you say more about why?


- Ellen

Expert Comment

ID: 11905727
Here are two comments from the memo:
"This memo does not specify an Internet standard of any kind."
"HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key."

I would definitely say HMAC is a industry suggested way of doing Message Authentication, but not a defacto standard (like say smtp, or http).

The reason my suggestion was as above is the pure definition of MAC in and of itself, which is defined it the above rfc as:
Typically, message authentication codes are used between two parties that share a secret key in order to validate information transmitted between these parties.

A simple cookie does not fit very well in the above statement.  First of all a cookie is sent one way, and that has no information you wouldn't already have because you placed it there.  It appears to me that your original intent was to store information securely in a remote location, which is very different then encypted data from point A to send to point B because point B does not have the information.  MAC enhances the encryption by making "secret handshake" when the data is passed.  If the handshake is wrong, you know that the data may not be valid.

What it appears you are trying to do, to me, is simply put a cookie on known client machine so that the next time client connects you can verify in advance using the cookie.  I would suggest NOT storing any information on the client, because in the unlikely even someone figures out how to unencrypt your message, they can impersonate almost anyone.  Instead, I would suggest not storing actualy information there because they would have nothing to unencrypt (because of the one-way hash).

I'm looking at it like this.  Some of the first types of authenticate looks alot like a simple hash algorthym.  Client A wants to log into Server X.  Client X knows Client A password.  To keep things secure Client A does not send the password to Server X.  What Client A does is hash his password (and other information), and sends it to the Server X.  Server X can then say use the same information (IP address, password, username) and use the same one way hash.  If the hashes match you have a winner.  Obviously current day authentication is much more advanced (secure tunnels).

However, in your case, your client has NO say in what the cookie is, unless they are attempting to "fake" authentication.  The goal is to prevent "fake" authentication.  We could look at this like a phone call.  Someone calls, you give them "something".  The next time you call, they give you this "something", you verify it by hashing the Caller ID phone number (and whatever else you want), and you're good to go.  A simple SHA hash of IP/username/password, storing it in a database would do the trick.  You aren't giving the Caller any encrypted information that they can use to try and unencrypt.

The biggest downfall of all of this is Network Address Translation (or Proxy).  I don't believe there is anything you can do to prevent this from allowing impersonation.  I have a hardware firewall at home.  You're website will see my Windows XP box ip address as X.  You will see my Server 2003 box ip address as X.  I don't know of anything that would prevent me from moving the cookie from my XP box to 2003, and not logging in.  This may seem insigificant, but there are companies that have thousands of employees behind a single IP address.  I don't know who is using your application, but you may have to take into account this possibility

Expert Comment

ID: 11905745
(in my above post, I miss typed "client X" which should be "client A")

Expert Comment

ID: 11905753
(i'm going to shoot myself,  "Client X" should have been "Server X")

Featured Post

Get 10% Off Your First Squarespace Website

Ready to showcase your work, publish content or promote your business online? With Squarespace’s award-winning templates and 24/7 customer service, getting started is simple. Head to Squarespace.com and use offer code ‘EXPERTS’ to get 10% off your first purchase.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

You do not need to be a security expert to make the RIGHT security. You just need some 3D guidance, to help lay out an action plan to secure your business operations. It does not happen overnight. You just need to start now and do the first thin…
A discussion about Penetration Testing and the Tools used to help achieve this important task.
Nobody understands Phishing better than an anti-spam company. That’s why we are providing Phishing Awareness Training to our customers. According to a report by Verizon, only 3% of targeted users report malicious emails to management. With compan…
The Email Laundry PDF encryption service allows companies to send confidential encrypted  emails to anybody. The PDF document can also contain attachments that are embedded in the encrypted PDF. The password is randomly generated by The Email Laundr…

600 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question