But by doing that you're exposing how your app validates the authentication key, leaving it open to being transferred to another
machine.
True. Although I'm only exposing a part of the auth chain, not *how* that is constructed to produce the actual authentication token. It does not, however, tie the session to a specific browser instance on a remote machine; this is a problem. Of course, if the hash token uses the reported UA when created... :P
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. But as you said, it's a reasonable thing to guess that it's being used as a salt or verifier, and may be spoofed using semi-random UA strings if you are testing for remote session hijacking weaknesses. If my salt changes according to a time/date/other, or is produced at random (somehow), even if it is transferred, it should still expire and be invalid by my own control.
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.
I would think it's because browsers are flaky and you can't really rely on them, and that means you can't build it into the system check.
That's the definition of a session. It's a server-side store of data related to a single user of a web application.
I think this is another reason why the internals don't support authentication of sessions. Is it up to a session to authenticate itself? Should it be? What if you wanted to override that behavior?
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 agree. :D
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.
Ah, so. You are right...
But you're right, the everybody-else-does-it-that-way argument is never very strong, but I think it's worth noting.
I don't mind "this is standard practice," but EXPLAIN what you mean. What standard practice? This is an area that I want my knowledge to overlap others... Bruce Schneier, in all his glory, makes this point about roll-your-own security solutions: Bruce Scheier, http://www.schneier.com/essay-031-ft.txt
The submission document for the algorithm I submitted with my colleagues at Counterpane was the length of a book. This [make hashing algorithms] is hard to do. But even normally rational people tend to be blinded by a bright shiny new algorithm. It seems so easy. The unfortunate truth is anybody can design an algorithm that he himself cannot break. It's actually profound. Anyone out there, from the best cryptographer to the random person on the street, can sit down with a pencil and paper, design an algorithm and say, "I can't break it." And then here's the fallacy—because you can't break it, you make the following assumption: "Therefore, it must be secure." So we end up with lots of proprietary algorithms. We have a lot of amateur cryptanalysts who will design the algorithms, do some work and then say, "Look I can't break it, therefore it's secure." My feeling is that if the designers haven't proven themselves by breaking several published algorithms, why should I look at their designs? The odds of them being secure are pretty negligible. Indeed, the top five AES candidates—this is top five based on a formal poll of cryptographers—were actually designed by teams that have cryptanalysts on them. They seem to be the fastest, the most elegant, the best performing, the ones that seem to be the most secure. Still, nobody trusts them—give us a couple of years to stare at them. Eventually, we're going to have a new standard. There's no reason that I can think of ever to use a new and unanalyzed algorithm. There's never any benefit. There might be the personal pride of the designer. Other than that, you might as well use a known algorithm. So the moral there is "never, ever trust a proprietary algorithm."
I have to admit that some of this back-and-forth comes from my desire to get what I want out of your responses, which I know is probably a little frustrating. How do people who know little about PHP know what session best practices are, spelled out? I'm not a noob, but I've still learned a good deal from your responses that I didn't know before. What about the OP?
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.
Sure, but referring to how long they've been around is a sore replacement for referring directly to what they say (the best practices, that is...).
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.
In all reality, I actually agree with you about sessions in my heart-of-hearts (maybe a little more now after this thread), as they are the simplest to implement, and the checks performed on authentication are as robust as any involving cookies (which can become hopelessly bogged down in checks, digests, and rechecks), although I posit the SAME thing can be achieved with instances of cookies. However, simplicity should be the operative word, and the complexity of the approach I have described is more than a little troublesome.
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.
When put together *with other data* unknown to the browser... This is a small difference. The auth key is not generated exactly from the hash digest (sha1($clienthash) !== $authkey).
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.
Or is it like have the three numbers on the back that are "supposed" to prove you have it physically in-hand? I think this is more accurately what I am describing.
Do you now see why my way is more secure than yours?
Of course not. Mind telling me again?! :D I appreciate that you posted the historical information on sessions and cookies. Whether it's accurate to reality, I don't know, but it makes sense, not lemons, so for now, it's good enough for me! p.s. Maybe everyone wasn't around when that history occurred... -- Jared Farrish Intermediate Web Developer Denton, Tx Abraham Maslow: "If the only tool you have is a hammer, you tend to see every problem as a nail." $$
