Fog Creek Software
Discussion Board




Winning the Cookie argument

We're tendering for a web-based project. Our solution uses ASP.NET. ASP.NET has a nice and straightforward Forms Authentication module that uses an encrypted cookie to keep your logon session. We use it. The client is asking can cookies be disabled.... AAARRRGGGHHH!

This sort of thing ("cookies are bad") should have stopped years ago - but we still come across these muppets that think they're some sort of privacy problem (yes I know about 3rd party cookies). How do you get these twits to wake up and realise that they're an essential part of the web and that 99.999% of users would never think of disabling cookies anyway (nor know what they are).

Note: ASP.NET Session can be cookieless, embedding a session id in the url, but not Forms Authentication. We could write a authentication mechanism built on ASP.NET Session, but what would be the point-- to placate an utterly flawed argument? Also storing a session id in the url when it's being used for authentication is also more open to session hijacking too.

Duncan Smart
Wednesday, August 13, 2003

Can the forms module be configured to use URL rewriting for maintaining session context?

Reginald Braithwaite-Lee
Wednesday, August 13, 2003

"what would be the point-- to placate an utterly flawed argument"

Well, if you don't do it, and it's an important enough point to them, they can just take their business to someone more cooperative.

That said, I agree with you entirely. It's asinine not to use cookies in this day and age and, accordingly, almost all users have them enabled.

"How do you get these twits to wake up and realise that they're an essential part of the web and that 99.999% of users would never think of disabling cookies anyway"

Provide metrics. There are articles/studies written on this, with numbers more scientific than "99.999%".

If you approach things with an "I'm glad you brought this up. It was once a legitimate concern" approach, cite experts' articles, and provide examples of big, important sites that do use them (Hotmail, Yahoo Mail, Amazon, eBay), that should suffice.

If your client is so stupid and stubborn that they won't concede a minor point like this, it's a bad sign. Do you really want them? Are they going to micromanage the whole way? Are they going to be obstinate on more important issues?

Joe
http://www.joegrossberg.com

Joe Grossberg
Wednesday, August 13, 2003

Duncan,

Have you considered trying the approach used by the Microsoft Mobile Internet Toolkit? Mobile Forms Authentication builds upon Forms Authentication, but uses the query string to convey the authentication ticket instead of a cookie.

For more information about Mobile Forms Authentication, see article Q311568, “INFO: How To Use Mobile Forms Authentication with Microsoft Mobile Internet Toolkit” in the Microsoft Knowledge Base.

Mark
----
Author of "Comprehensive VB .NET Debugging"
http://www.apress.com/book/bookDisplay.html?bID=128

Mark Pearce
Wednesday, August 13, 2003

"we still come across these muppets that think they're some sort of privacy problem "

Because they are.  Is it a "GIANT" problem, no.  But, if you are handling classified data, as an example, cookies are out.

"How do you get these twits to wake up and realise that they're an essential part of the web and that 99.999% of users would never think of disabling cookies anyway (nor know what they are)."

LOL.  Well, you don't.  Unless you are wording the statement incorrectly, they are not complaining about cookies being on/off they want a cookieless(?) solution.

Are you sure you are mad at the right issue?

If it does bother them, Mark has a good link.  Choose another solution and move on.  Doing so may be more work but so what?  There are some bridges to die on, is this the one you really want to choose?

MSHack
Wednesday, August 13, 2003

Eh? What's the relation between classified data and cookies?

(Note: 3rd party cookies are not the issue here. This is a session cookie. BTW, have you mentioned that you're using a session-cookie which isn't even saved on the user's machine?)

mb
Wednesday, August 13, 2003

Mark -- thanks, that looks interesting. I'll look into it. If this can be solved with little or no code then great - I'll grin and bear it.

Duncan Smart
Wednesday, August 13, 2003

If we are talking about a session cookie, explain that some kind of mechanism is needed to identify which client sent what for the app to work. Session cookies are the most secure form of doing so.... I guess.

Eric Debois
Wednesday, August 13, 2003

Cookies aren't evil but they aren't great citizens either. The problem is that there wasn't a good delineation of session and persistent cookies from the beginning. If there were only session cookies, there wouldn't be a problem. It's only now that browsers are giving users a choice to accept all session cookies while selectively accepting persistent cookies.

pb
Wednesday, August 13, 2003

Cookies *are* a privacy problem. That's why many people disable them. Cookies are not needed to maintain state, so either do what the customer says or give them an opportunity to turn the  contract over to someone who will do what they want. Their concerns are legitimate. And you, my fine friend, are acting incredibly unprofessional calling the people who are paying your salary twits, etc.

Dennis Atkins
Wednesday, August 13, 2003

Dennis,

"Cookies *are* a privacy problem. That's why many people disable them."

Session cookies are *not* a privacy problem and most people do not disable them.  With cookies disabled you have a hard time doing anything useful on the web (logging into sites, doing online banking, etc).

"Cookies are not needed to maintain state, so either do what the customer says or give them an opportunity to turn the  contract over to someone who will do what they want."

The purpose of Cookies is to maintain state!  Now you are correct, they are not *required* to maintain state.  You can use URL rewriting to make sure all your links contain a session ID parameter.  And then you can make sure that every form contains a hidden field also containing that session ID.  Of course, this really a nasty hack and there are lots of cases where it doesn't work right.  Furthermore, all your links end up looking like crap.

"Their concerns are legitimate."

No...  their concerns are not legitimate.  They are just uneducated and someone needs to bring them up to speed.

Almost Anonymous
Wednesday, August 13, 2003

>>"Cookies are not needed to maintain state, so either do what the customer says or give them an opportunity to turn the  contract over to someone who will do what they want."

Well, if state needs to be maintained, you have the same privacy issue regardless wether you use the session mechanism or not, because that is basicly the only thing a sessioncookie does. (AFAIK)

Eric Debois
Wednesday, August 13, 2003

Rather than just saying there is a privacy issue can
someone explain what that issue is specifically?

valraven
Wednesday, August 13, 2003

Session cookies are not secure. Just because they are not written to disk does not mean that are not vulnerable to man in the middle attacks (a google search can explain them better then I can).  By staying only in https and ensuring that only one browser window is open can one avoid a man in the middle attack.

The other misconception I had was that when the secure flag of a cookie is set and the cookie is only set in an https connection that the cookie is then only readable in https mode. I have found this not to be true at all. The cookie can be read in http mode which means that it is not 'secure'.

The session life span is the life of the browser being open. If more then one window is open on some browsers then the session does not end until they are all closed. So just making a user close the one window they are in when they log out does not mean the session cookie is lost. I would also recommend some javascript to make sure they logout before they close the current window, thus formally notifying you that their session is closed.

Uing just a url sessid is not 'secure'. If I send an IM to my friend with the url of the site with that value, that person then becomes me. Now people say that you can identify a web user by their IP address sent by the browser but this is not true. On some networks, AOL and Bell South for example the IP address of a user can change several times within an hours time. Also any information sent by a browser can be faked, like an IP address. Also in order to not have the url sessid sniffed out one needs to make sure that it is not sent before the client is connected via https.

Now the idea of timing out a session comes into play. This can be ok as long as you deal with your redirection properly. It would really suck to have just filled out a big form to then go to the bathroom come back, hit submit, get a timeout message and loose all the information you just posted. Making it so the user is asked to re-login is ok, just make sure their form information is preserved in some session variable.

Taking all of this into account I figure it is best to use a combination of a url session id and a session cookie with a value different then the sessid in the url. By using both of them you can be safe from the user IMing the url and you can also know when a user loggedout by simply closing the browser and then have someone else just open the browser and click on the history and get back into the account. Timing out a users session is also a good idea as long as you control the form problem I describe above properly. Timing out a session is also good for things like a laptop battery drainging and the machine saving the current system to HD before shutting off and then when the charger is steped on and the machine goes into the repair shop the repair man cannot just start using the site from where you left off.

That has been the best design I have been able to come up with to secure a website. Hopefully someone knows of a simpler way!

Jeff
Wednesday, August 13, 2003

"That has been the best design I have been able to come up with to secure a website. Hopefully someone knows of a simpler way!"

The majority of the time that's overkill.  And when it's not overkill you should be using SSL. 

Secure session cookies are not supposed to be visible in non-secure mode (as per the cookie spec RFC 2109).  However, IIS has a bug and doesn't discern between secure and insecure cookies.  If you are running IIS, there is a patch from Microsoft to fix this problem.

Almost Anonymous
Wednesday, August 13, 2003

>"If I send an IM to my friend with the url of the site with that value, that person then becomes me. "

And if you send your username and password to somebody, that person becomes you.  OF COURSE if you send somebody private identifying information they'll be able to impersonate you.

NoName
Wednesday, August 13, 2003

Their concerns are legitimate, assuming that the public will be using their website. If it's some private intranet site then none of this is an issue.

Cookies have been used by ad servers to track your visits across site boundaries. And at some point, you might log in to one of those sites, potentially tying your actual identity to all the sites you visited 'anonymously'.

"But Denis you are such a dumb ass this is not an ad server, it is a company site. You so stupid! Ha ha! This is not an issue! It is irrelevant! You are uneducated dumbass!"

Actually, it is relevant because of the privacy issue, a substantial number of people disable cookies, especially educated people with money who are potential customers. If you designed and maintained web sites like I do, you'd know that a lot of people visiting your sites disable cookies. Therefore, if you require use of cookies, you are choosing to eliminate the ability of a good portion of your potential clientele to use your web site to send you money. This is something that is known to professional web site developers.

Honestly, I don't believe that 1/10 of the people on this bulletin board are actually developers or they would know this.

Dennis Atkins
Wednesday, August 13, 2003

right, the final answer is there:
session cookies are not (inherntly) a security risk.

many people are confused by the two types of cookies and turn them all off. so much so that it's now the law in some country (norway?) to warn people of them.

your site needs to take this potential loss of users into account.

note that as mentioned above, url session ids themselves are worse than cookies. people cut & paste urls because they are supposed to be pointers to locations, not passwords. also, my isp has a helpful 'check your email' form. turns out it does some GET redirects, sends the whole password in the URL. now anyone can browse history in the internet cafe where I used this and they'll find my password. thanks.

of course, cookies and session ids must always be temporary, maybe refreshed indefinately, but they must expire, since both can be ressurected.

mb
Wednesday, August 13, 2003

"Actually, it is relevant because of the privacy issue, a substantial number of people disable cookies, especially educated people with money who are potential customers."

Educated people would disable 3rd party cookies only.
Uneducated people leave the default.
The people in the middle get the message pretty fast when they can't use any websites.

I'm the web developer and technical support for a good sized website (1,000,000 hits a month / 5,000 registered users).  It's a non-technical website (Coffee-related) and we get a very wide range of users.  I can count on one-hand the number of users who contacted me about having problems using the site because cookies were disabled. 

Almost Anonymous
Thursday, August 14, 2003

"many people are confused by the two types of cookies and turn them all off"

They're not necessarily confused, it may be that their browser does not support doing them separately.


Thursday, August 14, 2003

> And if you send your username and password to
> somebody, that person becomes you.  OF COURSE if you
> send somebody private identifying information they'll be
> able to impersonate you.

The point is you're copying/pasting an URL that *happens* to have your ID info, and you didn't noticed it.

Your goal is not to give your ID info, just to send someone an URL.

Paulo Caetano
Thursday, August 14, 2003

I am the litigating attorney who represents the Jim Henson estate. Please cease and desist the unlicensed use of the Henson trademark "muppet." Continuing to illegally use the word "muppet" without expressed written consent will result in the appropriate legal action. The Jim Henson estate considers such behavior to be unaccetpable and is contrary to the goodwill of the Muppet trademark.

Aaron Goldstein Associates
Thursday, August 14, 2003

Stick a cork in it.....

Ms. Piggy
Thursday, August 14, 2003

"Secure session cookies are not supposed to be visible in non-secure mode (as per the cookie spec RFC 2109).  However, IIS has a bug and doesn't discern between secure and insecure cookies.  If you are running IIS, there is a patch from Microsoft to fix this problem."

The problem is that the browser sends the cookie info no matter what so a person can do a man in the middle attack on the supposedly secure cookie. I have seen this happen with IE 6 and Netscape 7.1. By leaving this up to the server a malicous server can take advantage of the situation, thus I feel they are not to be trusted.

As far as SSL being the end all solution it is not. It will only solve the man in the middle problem. It will not protect a user from sending an IM to someone else or from someone just going back in the history and then getting full access. As far as it all being overkill that depends on the amount of risk a client is willing to take and how important it is to do things the best way possible.

The other option is to require the user to send an ssl identification certificate, but man that is pain in the butt for a user to do. I delt with a bank that does that for their wire transfer application and it was quite a learning curve for the accounting group to try and get it working before having to call us to help them out. I also am not sure how that will protect a user against someone browsing history and going at it that way. I have never written a web application that uses such technology.

People turning off cookies is a problem. To get around this and still be reasonably secure is even more of a problem. From what I can tell you need to move away from standard html web apps and move to things like Java apps that are connected via ssl that can do session state within the client side code. This is the way several banks we deal with have gone and it seems to be working quite nicely for our accounting group. This has become more apparent with some of the new wireless devices that don't support cookies, guess I am going to have to figure out a good way to deal with that?

Jeff
Thursday, August 14, 2003

"Honestly, I don't believe that 1/10 of the people on this bulletin board are actually developers or they would know this."

I am a developer, and I do watch to see how many people have cookies disabled. It's essentially zero. Ditto for people who have disabled JavaScript.

Brad Wilson (dotnetguy.techieswithcats.com)
Thursday, August 14, 2003

Does anyone know what Jeff is talking about?

pb
Thursday, August 14, 2003

Yes.

mb
Thursday, August 14, 2003

He's talking about cookies

Keep up pb
Friday, August 15, 2003

or you could tell them to get a moderm browser with decent cookie management features.

fool for python
Friday, August 15, 2003

*  Recent Topics

*  Fog Creek Home