--- "John W. Holmes" <[EMAIL PROTECTED]> wrote:
> > > So let's say the first user comes along and is given the userid 1.
> > > We then create their random id by adding 241757219 to their userid.
> > > We get a random id of 241757220. Then within the login page I can
> > > subtract 241757219 from their random id and get their userid.
> > >
> > > Since the userid will always be unique (auto-incrementing) it
> > > stands to reason that the random id (using the method above) will
> > > also always be unique while at the same time not making any sense
> > > to a potential attacker. (It could even be made more complicated
> > > but use the same method.)
> > >
> > > How does that sound?
> >
> > Sure. Since a potential 'hacker' doesn't know your base number, it
> > would be pretty secure.
>
> Not a good method. If I get on your site and see my cookie has the
> value 241757219 in it, I just need to subtract one from the number
> and revisit your site. Now I'm the user who registered before me.
> Using the rand() or uniqid() method above means I have to guess an
> entire random number / character sequence, which is going to be harder
> (or nearly impossible).
John makes a good point (of course). In addition to this, however, you should
also try to take steps to ensure that a guessed ID is less likely to work for
the bad guy. Depending on the obscurity of the session ID alone isn't enough if
that's the only thing a bad guy needs to be able to impersonate one of your
users. Cookie vulnerabilities, client-side caches, bookmarks, and other things
can cause the session ID to be disclosed.
Each request that a client sends likely has some information that can help in
this regard. Although you should never depend on information gathered from the
TCP/IP layer, it is safe to depend on the consistency of certain HTTP headers.
For example, if a user agent identifies itself as "Mozilla/5.0 (compatible;
Chris's badass Galeon browser) Linux/2.4" in one request, it is pretty safe to
assume that it will identify itself as such in future requests as well. If a
future request, using the same session ID, identifies itself as "Mozilla/5.0
(Joe Schmoe's lamass IE browser) Windows SA", does it makes sense to resume the
session without question? It doesn't make sense to me.
If a browser accepts gzip encoding now, will the same browser accept it in the
future? There is a lot of information you can use to make impersonation a
little more challenging for the bad guys, and every little bit helps.
Just as a friendly note, IE alters the value of the "Accept" header in the same
session, depending on whether the user clicks a link or clicks refresh. This is
annoying behavior, but it demonstrates the risk in taking this technique too
far. You don't want to enforce a restriction that impacts the good guys.
Hope that helps.
Chris
=====
My Blog
http://shiflett.org/
HTTP Developer's Handbook
http://httphandbook.org/
RAMP Training Courses
http://www.nyphp.org/ramp
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
