Since most people love cookies, I thought I’d explore the web cookie topic. Some people have the misconception that cookies can do nefarious things to your computer like copy your files, reveal your identity or damage your computer in some way. As a web user you should understand what cookies do and some of the privacy concerns they raise. With this knowledge I hope you can make an informed decision on what kinds of cookies you allow or block at the browser level, based on your comfort level.

Let’s say you open your browser and go to ‘http://www.amazon.com/‘. You’re visiting the site using a browser and acting as the client, while Amazon.com, running a web server is the server side. Webserver handles HTTP requests. HTTP is a stateless protocol, meaning, when I go to a page at Amazon, the Webserver sends the page to my browser and I see it. When I click on a book that I like, a new request is sent to the Webserver and a new new page is sent back to my browser. The Webserver has no knowledge of the previous page I clicked. They are like humans with no memory, constantly meeting new people. Now you’re going to ask, “What do you mean that Amazon.com is stateless when it shows my name when I visit and it seems to know what books I like?”. Good question. This is where cookies come into play. Cookies allow a webserver to interact with a client in a stateful fashion. A cookie is a parcel of text that is sent to the server with each request which allows the server to remember the client. There are different types of cookies used on the internet; persistent cookies and session cookies (or transient cookies). Each of these types of cookies can be turned on or off in the browser settings. A session cookie allows the webserver to know who you are as you move from page to page. Session cookies store information in the browser memory, which is available for the duration of the browser session. This information is only available as long as your browser remains open. If you close your browser, the session cookie information is gone. It’s called a session cookie for the reason that this type of cookie has a short life. For example, your bank’s site will establish a session cookie after you log on that is valid as long as you are interacting with the bank site. However, if you walk away from your computer for a snack, chances are your session will be invalid so that when you try to click on your checking activity, you’ll be prompted to login again. This ensures against someone walking over to your computer and viewing your private financial data.

A neat little trick to view your session cookie details is the following: Go to a site like ‘amazon.com’ or your bank site (really most sites establish a session cookie to know you as you move around). When you’re on that site, copy and paste javascript:alert(document.cookie)’ into your browser. You’ll see a bunch of name/value pairs. One of them is the SID or session-id, which is the ID that tells the webserver who is making the request. Very cool indeed.

The other type of cookie is called a ‘persistent cookie’. This cookie is actually stored on your computer in a little file with information that is used by the webserver to idenify you. When you return to a site that already has a cookie stored on your computer, the browser automatically passes on the cookie with the request. The webserver now has some identifying data. Now if you visit a site and see that your userid is already populated or if you go to, say, amazon.com and it says, “Welcome back Ron”, the persistent cookie makes this possible. If website A stores a cookie on your computer, website B can’t access the cookie. However, even if a website somehow was able to access a cookie from another site the information in the cookie would not make sense. Only the issuing website would be able to make sense of the data stored in the cookie. Another application of a ‘persistent cookie’ is that it can store information about you that will help the website create a page that was customized by you. The cookie files are stored in /Windows/cookies or in /Windows/profiles/username/cookies directories, where username is replaced with the user’s login name. If your operating system directory is not named Windows (such as Winnt for Windows NT) then look in that directory instead of the Windows directory. If you like, you can delete all of them or delete them for sites you don’t want to be storing cookies.

So what’s the bottom line? Are cookies dangerous in any way? Should I block cookies from being set? The truth is that cookies aren’t dangerous and cannot do anything detremental to your computer. Cookies can’t get any more information about you than what you give the website issuing the cookie. Also, cookies are not able to aid the webserver to read files on your computer.

A good practice that users employ is to browse the internet with cookies turned off by default. Once you visit a site and decide to trust that site, you can then proceed to add the site and allow your browser to accept cookies from this site. You can also view the site’s privacy policies to make sure that you’re comfortable with their policies.

In a future post I will talk about third-party cookies. These cookies raise privacy concerns, since they allow ad companies to track the different types of site you visit and then tailor their ads based on the data collected.

Steve Gibson of “GRC.com” has successfully implemented a very cool and extremely robust multi-factor authentication for his GRC employees who need access to an web admin console. He shares his implementation on a series of pod-casts found here. The cool thing about this form of authentication is that he assumes “perfect knowledge”. This means that Steve’s one-time password scheme is extremely secure. So secure, in fact, that if a keystroke logger residing on that machine is recording the keystrokes while a user attempts to log in – that information would not aid an in future attempts to log in. Most sites you visit that contain the typical user log-in, including your online banking site, would be vulnerable to a key stroke logger attack. That is because they require a password that is static. This means the password doesn’t change each time a user logs on. A key stroke logger would be able to identify your password as you type on the keyboard. Armed with this knowledge of your password the attacker can masquerade as you in a future log-on attempt. Another term for this attack vector is called a “replay attack”.In the Steve’s “PPP system” the four-character password, which is a passcode, is different each time the user logs on. There are 16,777,216 possible combinations for each passcode and since no passcode is ever reused, a replay attack would be impossible. The passwords are displayed on a credit card sized piece of paper that can be easily stored in one’s wallet. Steve uses some heavy duty encryption with a highly pseudo random 256 bit key to generate these series of passcodes. Each user will have a 256 bit key that will define the series. This key is stored on the server and the user doesn’t know this key. Another nice feature with this system is that the server will keep track of the passcodes of prior logons, and prompt the user for which passcode that it wants the user to enter. Each column is a letter and each row is a number, therefore the server might show “3E [1]:” so you would type in 5th column 3rd row on the first page. You can also print out your own passcode sheets and if you ever lose a sheet you can tell the server to forward you on to the next sheet, invalidating
the prior passcodes.

The PPP system was well received in the security community and some very practical open-source implementations were created. I downloaded and installed the PPP for PAM module, which allowed me to use PPP when I remote log-on to my MAC using SSH. Interestingly, Steve mentioned that when his employees log on using PPP they also supply a static password in addition to the PPP password. The reason behind this is that if the sheet of passcodes (something you have) got into the wrong hands they would be able to log in as you. However, they still need the static password that only you know, to log on.