Encrypted cookie (MAC) - industry standard?

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?

Who is Participating?
ErikPhilipsConnect With a Mentor Commented:
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.
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.)
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)
Improved Protection from Phishing Attacks

WatchGuard DNSWatch reduces malware infections by detecting and blocking malicious DNS requests, improving your ability to protect employees from phishing attacks. Learn more about our newest service included in Total Security Suite today!

equaadAuthor Commented:
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
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
(in my above post, I miss typed "client X" which should be "client A")
(i'm going to shoot myself,  "Client X" should have been "Server X")
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.

All Courses

From novice to tech pro — start learning today.