Re: Re: a question on session ID and security

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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." $$

[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux