Re[4]: [Phplib-users] new Session4 changes

[Maxim D. <max...@bo...>]

RH> I'm not following.  If the session doesn't have an IP then it's not valid?
Right, it's not valid since it doesn't "exist" yet (in case when we
always save client's IP, with every request). If we have a SID, but
the session, associated with the SID is empty (or, at least, does not
contain an IP, which should be there), than the most probably that the
SID was hand-crafted or obsolete (the new session is born
automatically), so we trash this SID and issue a new one, with a new
session.

RH> What if the IP doesn't match? Is it invalid also?
This depends on your policy. I suppose, the "less evil" would be to
close the session if the SID comes from anything but the cookie (we
have 4 sources for SID in PHP). Cookie-enabled clients won't suffer.
But the right way is of course to make this behavior turned on/off as
desired.

RH> Most search tools ignore redirects as well as javascript, etc.  We are
RH> talking about protected sites that people do not want indexed anyway.  If
RH> they were for public consumption, then there would be no need to protect
RH> them.
Wrong. Tell this to Amazon :) The public sites must be protected, if
they are not going to loose their clients.

RH> There is no good way of addressing this.  There are many papers, etc. on
RH> doing so, but they are all at the protocol level and involve the user
RH> posessing a personal key signed by a trusted third party.  When DNSSec
RH> becomes more widely deployed, then there will be a reasonable way of doing
RH> something, but not until then.

We live just now. And when somebody can snoop into your personal
details without any serious effort, the problem should be solved.

RH> As it stands now, if the client has cookies enabled, then there is a fairly
RH> secure way of tracking them.  If not, there is not a secure/reliable way.
RH> That is the whole reason cookies were invented.  To store bits of data on
RH> the client's machine because there was no reliable way of tieing it to them
RH> next time.  How are you going to handle HP, which has a whole class B block,
RH> but also has several thousand IPs behind masquerading machines.

I do know about proxies and masquerading. I also know that a dialup
users often receive a different IP after reconnect. But we should
decide what should be more secure way - to let everybody take over
someone else's session or restrict them. We can not make all the
people to use cookies.

RH> The IP address can easily be forged.  It is called a man-in-the-middle
RH> attack, and in this case, simply requires that you have a machine that is
RH> behind the same proxy server or nat device to defeat this scheme.

Yes, but if we have a man in the middle, all the efforts are useless -
he can simply sniff our traffic. Cookies won't save us, only SSL will.

RH> I vote that the documentation cover the security aspect, and leave it at
RH> that until there is a widely deployed public key system that can be
RH> leveraged instead of trying to invent something that provides an artificial
RH> sense of security and will cause problems.

We don't invent something - look at Amazon, again. They are always
provide SID in the URLs, but I've never heard that they are
vulnerable. They don't use pubkeys, they have their pages perfectly
indexed by robots, and they deal with the problems, somehow. Try to
access their pages with someone else's SID. We can endlessly discuss
the theoretical matters, but we live now and should deal with this
now, somehow, and should not wait for someone with the magic wand, I
suppose.




-- 
Best regards,
Maxim Derkachev mailto:max...@bo...
IT manager,
Symbol-Plus Publishing Ltd.
phone: +7 (812) 324-53-53
www.books.ru, www.symbol.ru