Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win


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
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 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)
Put Machine Learning to Work--Protect Your Clients

Machine learning means Smarter Cybersecurity™ Solutions.
As technology continues to advance, managing and analyzing massive data sets just can’t be accomplished by humans alone. It requires huge amounts of memory and storage, as well as high-speed processing of the cloud.


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

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

A bad practice commonly found during an account life cycle is to set its password to an initial, insecure password. The Password Reset Tool was developed to make the password reset process easier and more secure.
What monsters are hiding in your child's room? In this article I will share with you a tech horror story that could happen to anyone, along with some tips on how you can prevent it from happening to you.
Sending a Secure fax is easy with eFax Corporate (http://www.enterprise.efax.com). First, Just open a new email message.  In the To field, type your recipient's fax number @efaxsend.com. You can even send a secure international fax — just include t…
With Secure Portal Encryption, the recipient is sent a link to their email address directing them to the email laundry delivery page. From there, the recipient will be required to enter a user name and password to enter the page. Once the recipient …

618 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