Solved

Encrypted cookie (MAC) - industry standard?

Posted on 2004-08-24
7
371 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
[X]
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
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
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 

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

Forrester Webinar: xMatters Delivers 261% ROI

Guest speaker Dean Davison, Forrester Principal Consultant, explains how a Fortune 500 communication company using xMatters found these results: Achieved a 261% ROI, Experienced $753,280 in net present value benefits over 3 years and Reduced MTTR by 91% for tier 1 incidents.

Question has a verified solution.

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

Suggested Solutions

If you are looking at this article, you have most likely been hit by some version of ransomware and are trying to find out if there is anything you can do, or what way you should react - READ ON!
Smart phones, smart watches, Bluetooth-connected devices—the IoT is all around us. In this article, we take a look at the security implications of our highly connected world.
Email security requires an ever evolving service that stays up to date with counter-evolving threats. The Email Laundry perform Research and Development to ensure their email security service evolves faster than cyber criminals. We apply our Threat…
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…

738 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