Eugenio Marongiu - Fotolia
In a previous article on RC4 cipher attacks, you wrote that applications should use session cookies that are salted...
hashes changing with every request. Can you elaborate on this practice? I don't usually encrypt the values of session cookies because I know they are transmitted over HTTPS protocol. If a session cookie contains sensitive data, I usually generate an encryption key for the whole session and I delete the key after the session expires. Would this be a suitable alternative to encrypting just the cookie? And if not, can you specify what type of session cookies and data should be protected by hashing and salting?
The article you mentioned on RC4 cipher use in the enterprise covered a new attack that can break the RC4 cipher and successfully determine values in a user's encrypted cookies. These values could then be used to gain unauthorized access to information or services. The attack is not limited to encrypted cookies but any data or information that is repeatedly encrypted; this is why web developers should ensure that session cookie values used to access sensitive information are a salted hash that changes with each server response. This will provide protection against brute-force attacks like the RC4 NOMORE technique described in the original article.
Before I explain why this works, let me look at your own cookie encryption implementation. A session is a way to identify and manage the state and the session variables for a particular user through multiple browser requests. Cookies are the preferred method for managing sessions as they don't get cached, and aren't visible in the URL or referrer logs. However, information stored in session cookies can be modified or spoofed, so sensitive information should never be stored in a cookie.
You need to be aware that sending a cookie over HTTPS only protects it as it travels over the internet. The cookie values can be read in plaintext at the client end. Using an encryption key for each user session to encrypt cookie values provides some security, but the level of protection depends very much on how the encryption key is created and the algorithm used. As the RC4 NOMORE attack shows, if the same information is repeatedly encrypted the same way it can be recovered in certain situations. This is why it's important to constantly change the salt used on encrypted cookies storing sensitive information. The salted hash will make brute force and precomputed rainbow table attacks less viable.
A more secure way of using cookies is to only use it to store a session token -- the unique identifier for a specific session. Any other session data that needs to persist across requests is stored on the server and linked to that session token. PHP, Cg, ASP and JavaServer Pages programming languages all offer this functionality. Attackers are constantly finding new ways of hijacking sessions and stealing information stored on the client, so session and authentication management methodologies should be regularly reviewed to ensure that they follow best practices. This includes changing session cookies that provide authenticated access to any type of sensitive data with every client request and server response.
Find out if your enterprise's security is threatened by mobile persistent cookies
Compare the differences between hashing and encryption
Learn how the LastPass data breach exposed customers' password hashes
Dig Deeper on Web browser security
Related Q&A from Michael Cobb
Sending sensitive information in attachments is inherently unsafe, and the main way to secure them -- encryption -- can be implemented inconsistently... Continue Reading
Spyware can steal mundane information, track a user's every move and everything in between. Read up on the types of spyware and how to best fix ... Continue Reading
Explore the differences between symmetric vs. asymmetric encryption algorithms, including common uses and examples of both, as well as their pros and... Continue Reading