Re: Re: a question on session ID and security

Jared Farrish wrote:

That's not what I'm saying. My basic question is why send the "secondary hash key" to the client when it doesn't need it? Use the authentication key to identify the users data, then get the "secondary hash key" from that data. The browser never needs to see the hash, and from a purist security point of view it could potentially reveal more about your security methods than you need to.

The idea is that the secondary hash key replaces the user agent sniff.

But by doing that you're exposing how your app validates the authentication key, leaving it open to being transferred to another machine.

But the point here is that both pieces of information required to authenticate that client are stored on the client. If someone can get one of them they can get the other, so it's no more secure than just accepting the one cookie without bothering to authenticate it in any way.

The token isn't any more secure than tokenizing a user agent and salting it into a digest. The client still knows what their user agent string says, and this string can also be guessed (how random can they be?), but at least you can manipulate a secondary hash key per day/hour, week, whatever.

It's actually less secure than using the user agent because someone looking at the cookies on the client gets no indication that you're using the user agent to verify that it's the same client making the request.

I have nothing against cookies at all, but I think the line between cookies and session data is pretty clear.

I would just ask where? (No, really.) If it was clear, then a link to a tutorial on PHP session security is helpful.

I've asked the internals list why PHP doesn't natively validate the session ID by using the user agent or other variables because I actually don't know the reasoning behind it. I'll let you know what they say.

Cookies should be used to... a) remember a user between sessions (but not authenticate them) b) remember a session ID during a session c) remember user preferences for anonymous users, or where there is no such concept as users on the site

I agree 100% on everything except the logic on authentication. How would you finish the following: Sessions should be use to... a) ? b) ? c) ?

a) Store data between requests b) There is no B That's the definition of a session. It's a server-side store of data related to a single user of a web application.

Sessions should be used for everything else. If you're finding that you're storing huge amounts of data in cookies, switch to using sessions. If you find that you're storing so-called "sensitive" information in cookies, switch to sessions.

I don't store anything in cookies that are meant to be useful on the server-side, save an auth string and a corresponding generated salt. This will probably change on my next big project, but for the moment, I'm not much of a fan of SESSIONS that persist. This is based on limited experience and anecdotal evidence, so opinions may very.

By "sessions that persist" do you mean sessions that live on between visits by a user? If so then that's a totally different kettle of fish and IMHO should be avoided at all costs.

I'm more than happy to discuss it, but please tell me you got the point about whatever extra security is possible is likely to have been added by the majority of web application platforms, including PHP.

Of course. We're talking methodology (implementation of what is available), so I'm not sure why you feel the above is necessary.

Look at the session facilities provided by any web development platform. They all work the same was as PHP sessions, that is to say storing a session ID in a cookie or passing it in URLs. I'm not aware of any system that uses extra validation, and the reason for that is that there is no guaranteed method. But you're right, the everybody-else-does-it-that-way argument is never very strong, but I think it's worth noting. As mentioned earlier, I have asked the internals list to give a reason why the session extension does no additional validation.

I'm all for talking about it and seeing if there is a better way, but I also know that people far smarter than me have been talking about it for over 20 years, and what we have is what they've come up with. Ignoring the other possibilities like client certificates there's not really anything more you can do without introducing the possibility or even likelihood that the user experience will be shafted.

If it's an accepted methodology, please describe the entire methodology. If you think it's obvious, it should be easy, and a link is beneficial.

20 years was an exaggeration given the age of the web, but the need to persist data related to any given user of a website between requests has been an issue for well over 10 years. The first "solution" was cookies. The problem with cookies is that they're very inefficient and insecure. Inefficient because they get transferred with every request, and insecure because they get transferred in the HTTP headers and get stored on the client over which the web developer has no control. The natural progression of this was to store the minimum required in a cookie, and tie that cookie value to a chunk of data on the server. This is what we now understand as a session. Client certificates were created to allow a client to prove its identity to a server in the same way that an SSL certificate can prove the identity of a server. Unfortunately the management of client certificates makes them uneconomical for most applications. I know of a few banks that use them, but not many at all. In fact, the only place I've used them lately was in a forex trading system where each terminal cost over $12k which included the hardware and the software license. In effect the client was as much in our control as the servers were. Anyhoo, I digress. Sessions are the answer to storing data related to a users visit to a website / web application between page requests in an efficient and relatively secure manner. Through the use of SSL you can add to the security my making it very very hard (but not impossible) to read the session ID at any point during its transmission. However, you are still left wide open at the client end, and this I think is where we differ.

I do think the stated best practice of SESSIONS, at this point, probably does need to be described to be further useful as a topic of discussion. I've been a little unclear in some things, so I get the feeling we've got the same point of view, with one slight deviation (I think it's slight...).

You want to store 2 pieces of information in the browser which, when put together, will allow a user to continue their visit in an authenticated state. I want to put 1 piece of information in the browser, and store the other in the session. The bit stored in the browser will identify a particular session on the server from which I will get the second bit. It doesn't really matter whether that second bit comes from the user agent, or is randomly generated on login. Storing the validation key in the same place as the key is like writing your PIN code on the back of your credit card. Do you now see why my way is more secure than yours? -Stut