Solved

Encrypted cookie (MAC) - industry standard?

Posted on 2004-08-24
7
356 Views
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?

Thanks!
0
Comment
Question by:equaad
  • 6
7 Comments
 
LVL 4

Accepted Solution

by:
ErikPhilips earned 500 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:
http://www.amazon.com/exec/obidos/tg/detail/-/0471117099/103-6143482-5423032?v=glance
(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)


OR


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

Expert Comment

by:ErikPhilips
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.)
0
 
LVL 4

Expert Comment

by:ErikPhilips
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)
0
Do You Know the 4 Main Threat Actor Types?

Do you know the main threat actor types? Most attackers fall into one of four categories, each with their own favored tactics, techniques, and procedures.

 

Author Comment

by:equaad
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?

Thanks,

- Ellen
0
 
LVL 4

Expert Comment

by:ErikPhilips
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
0
 
LVL 4

Expert Comment

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

Expert Comment

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

Featured Post

Highfive Gives IT Their Time Back

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

Suggested Solutions

This story has been written with permission from the scammed victim, a valued client of mine – identity protected by request.
This article explains in simple steps how to renew expiring Exchange Server Internal Transport Certificate.
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…
In this tutorial you'll learn about bandwidth monitoring with flows and packet sniffing with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're interested in additional methods for monitoring bandwidt…

757 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

Need Help in Real-Time?

Connect with top rated Experts

17 Experts available now in Live!

Get 1:1 Help Now