|
|
Posted by Gordon Burditt on 12/15/05 07:54
>>> And while Im at it... should I be using PHP's built in sessions, or
>>> use my own functions that I've chobbled together from various
>>> sources and takes advantage of also validating IP Addresses???
>>
>>
>>> I don't like to use things just because they're there.
>>
>>
>> I know what you mean, but if it's there and it's working well, then
>> use it.
>>
>> PHP sessions do work very well - except for one problem I found.
>>
>> MS IE kept using a different session ID for every page it requested !
>>
>>
>> I solved this by creating my own session ID and storing it in a
>> cookie, so I could get it back and force the same session ID each
>> time.
I have to wonder WHY this would fix the problem. What is better
about YOU creating the session ID and storing it in a cookie vs.
PHP creating a session ID and storing it in a cookie? Perhaps
someone is blocking the cookie 'PHPSESSID' and leaving others alone?
>Hrm... apart from setting a cookie and hoping (since you can't rely on
>PHP sessions), what you do isn't too different from what I do... I just
>pass a session id either in a cookie, or on the url, and verify it's
>still active with the right ip address...
>
>which brings me I think onto my next question... another poster said
>tcpip addresses are unreliable in some circumstances, so what else can
>you use to verify that someone else hasn't stolen someone elses
>sessionid and is using that account?
You CAN'T verify it as far as people are concerned. It is quite
possible for the user to get bonked on the head and someone else
continues his session for him. Governments do this occasionally,
and sometimes design the raids so they can do this to gather evidence.
There's also the "unattended computer" problem and the "shared
family computer" problem.
If you define "session" as "a period of time during which the user
sits down at a computer and uses your site", the main problem with
FALSE triggering of IP checks is round-robin proxies. Different
parts of the same page, or several successive pages, may appear to
be from different IPs. On the other hand, your test WON'T trigger
when it really should in the case of a whole office behind a NAT
gateway which may have only one public IP, and one guy in the office
is spoofing another's session.
If you define "session" as something longer, say, more than a day,
you run into the problem that users have more than one computer
(say, home and work) and want to use your site from both, and an
IP check will block that. Also, dialup users will probably change
IPs every time they redial.
Bank of America recently set up an interesting addition to their
online banking setup. You used to log in by entering a user
identifier and password on a web page. Now, after you've set it
up, it works like this:
1. You enter your user identifier on a web page and submit.
2. *IF* your computer has the cookie left by setting it
up, go to step 4.
3. Your computer doesn't have the cookie. It will ask you
one of three questions you set up and you have to
supply the correct answer you entered during setup.
4. The web page shows you an image and a caption you selected
at setup (For example, a fire-breathing dragon and the
caption "my mother-in-law"). Users are told NOT to
enter their password unless they see the correct image
and caption. In this way the user can be sure they aren't
on a spoofed web site.
5. You enter your password to log in.
6. You see the main page for online banking.
If you log in successfully and you didn't have the cookie, it will
ask if you log in from the computer you are on often, so you can
set up the cookie on several systems. However, DON'T set up the
cookie if you are logging in from an Internet Cafe or public library.
Depending on your memory and how much you might have to answer the
questions in an emergency, it might be a good idea to give illogical
answers to the questions (For example: what month is your wedding
anniversary? Answer: Saddam Hussein. One problem with this
approach is you have to remember how to spell the answer. I also
recall one guy had some irritating problems with his phone service
because he had put a password on it to lock out unauthorized changes,
and his password was 'Go f**k yourself', which had to be given to
human customer service representatives as well as on the web site,
but they didn't check the correct password before reacting badly.)
Gordon L. Burditt
Navigation:
[Reply to this message]
|