- If I use AppFog (or other PaaS)—which uses load balancers—I need to find out where the session data file will be stored in the file system; and, whether I need to modify my code so session data won’t be lost when the load balancer switches servers. There is some information about this in my post about my site v2 development environment.
- Transactional experience (Also, design it like other tax processing or web banking sites.)
- A session ID cookie gets planted.
- Allow 3 attempts to log in.
- Use same lockout scheme used in site v1.
- Currently Running Script (CRS)
- Current Session (CS)
- One session (CS) and one script (CRS) at a time.
crsTimestamp(beginning time of the CRS)
crs_hasChanged (this page is from a new script)
crs_isMatch (the form tokens correctly identify the CRS)
currTimestamp(time of page load)
LTOffset(local timestamp offset)
displayTime(local US formatted time + t_zone)
secretQuestionA(id of the question)
secretQuestionis stored in user’s database record.
SecretQAnsweris stored in user’s database record.
LTOffsetis stored in user’s database record.
sessionIDis stored in user’s database record.
ulkgIPis stored in user’s database record.
- Every page load should verify IP matches
- Authentication script verifies IP matches
ulkgIPin the database.
- If mismatch of IP occurs at authentication then ask both secret questions.
ulkgIP_hasChangedat regular page load then re-authenticate.
- Hidden form variables will be a secondary way of holding
- Every page load verifies matching session and form values for
- Mismatch of session and form values for
crsTimestampresult in deletion of older CRS data.
- Switching to a new CRS destroys the data of the old CRS.
- Every time the application is started in a new window or new tab a new use login session must be started and the old one destroyed. I’m not sure why but if it’s good enough for phpMyAdmin it’s good enough for me.
- Every page load verifies
currSessState::sessionIDmatches sessionID in the database. This prevents a user from ending up with more than one CS as a result of starting another CS using a different browser application or a different workstation.
- Mismatch of session ID will result in user being logged out.
- Additional rules to preserve the characteristics of a CS:
- Authentication results in a new CS.
- A new CS is one which is completely disassociated from the old one. See posts which talk about regenerating a session.
- Non-secure CRS must destroy a previous secure instance’s data and session ID.
- Secure CRS must destroy previous script ID and data if they belong to a non-secure CRS. This will be done by re-authenticating the user.
- Disable the passing of session ID by HTTP variables in the URL. Only cookies will be used for this functionality. This helps protect from session fixation attacks. Make use of the ini configuration called
session.use_only_cookies. See documentation.
- When a session expires the next page the user should see is the login page or login script. Keep in mind I’m implementing timeout functionality—user is logged out after 23 minutes of inactivity.
- Implementing timeout functionality—user is logged out after 23 minutes of inactivity. See related post to learn how this can be implemented using custom code.
- Use SSL and HTTPS to encrypt browser to server communication to prevent session ID sniffing and session hijacking. Having this feature site wide is impractical. Sessions for scripts which deal with less sensitive matters should not be encrypted. I can’t use SSL on all the pages because that would bog down the server and slow down my page loads—although some websites do it.
- Pages which do crucial or admin tasks need encryption.
- Pages with sensitive information need to be encrypted (i.e. passwords, employee home addresses, etc.
- Whenever switching to encrypted mode kill the existing session ID; make user login again; run SSL on all page loads for that script.
- If I use a third party login service like BrowserID I may not need to buy an SSL certificate.
- If my hosting doesn’t give me my own IP address then using SSL may be problematic.
forgot.phpscript should not send a visible new password. Instead it should email the user a link to a script which allows the user to accept and view their random password or change it—after answering both their secret questions and logging their IP address.
- Save button — next to the logout button should be a Save button. This is only for the administrator account. The Save button allows the database to be backed up to a local folder on the workstation. However, before the administrator does the save he should be able to view all the records which were changed since the last save (for added records it should retrieve the actual record from the database in order to display it).
- The confirm script should ask the use to enter their password because hackers use real emails that don’t belong to them in the hope that the owner will click the confirm link—assuming my site has a confirm script.