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 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.
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.
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) ?
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.
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.
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. 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...).
