Forum Moderators: coopster
Would you suggest this way
<snip>
or do you prefer some other way
Thanks and have a good day!
[edited by: dreamcatcher at 12:25 pm (utc) on Aug. 5, 2008]
[edit reason] No urls please! [/edit]
First and foremost you must determine the importance of security for your application; logging in to a counter site to check hits to your website is far less of a security worry when compared to banking or financial transactions.
The golden rule is that if a stolen cookie would result in substantial risk to the user then use only session cookies and time them out rapidly.
Simple additions to a basic security system include:
- Risk-factor based rejection (lose points for far-off IP location, unusual visit time e.g. 1am - 5am, IP is a known proxy, visit has proxy headers, browser different to usual, IP has visited site with other accounts, etc...; if too low then immediately require full verification for next login)
- IP change (every IP change requires logging in again)
- Usage profiling (long-term users have established patterns, e.g. log in, control panel, my threads; and favourite functions or areas e.g. check balance. A visitor coming in and reading his own account information and then going to read old statements can be recognised as a risk if that's not what he usually does)
A good compromise in some cases is to only store half of the login token in a persistent cookie; e.g. identify the login name to save retyping it and just require the password with each return trip.
AJAX is a very useful way of tying cookie validity to actual site visit time. Monitoring mouse move and key press events to the document means you know reasonably accurately when the user is no longer using the system; you can then log them out immediately (notify them on next action of the need to log in to continue). This avoids the problem of people who browse away from the site (in which case the session cookie still remains in their browser).
I'll follow your instructions and if somehow substantial risk will be detected, user will have to log in again only with password... username will be filled from cookie...
User personal info and editing existing profile will be possible only if (cookie)user enters password again for identity verification.
At every login random token will be generated and stored into cookie and database again to make it more complicated..
Very good idea with AJAX and mouse tracking for automatic user logout.
Thanks again, you said some thing I'd never figure myself (established patterns)
