site v2 user login features

Login Session

  • 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.
  • class currSessState
    • sessionID
    • isLoggedIn
    • crsPath (from web-root)
    • crsTimestamp (beginning time of the CRS)
    • crs_hasChanged (this page is from a new script)
    • crs_isMatch (the form tokens correctly identify the CRS)
    • currCRS_UsesSSL
    • prevCRS_UsesSSL
    • currTimestamp (time of page load)
    • LTOffset (local timestamp offset)
    • displayTime (local US formatted time + t_zone)
    • userType
    • username
    • firstName
    • lastName
    • middleInitial
    • secretQuestionA (id of the question)
    • SecretQAnswerA (string answer)
    • secretQuestionB
    • SecretQAnswerB
    • ulkgIP
    • ulkgIP_hasChanged
  • secretQuestion is stored in user’s database record.
  • SecretQAnswer is stored in user’s database record.
  • LTOffset is stored in user’s database record.
  • sessionID is stored in user’s database record.
  • ulkgIP is stored in user’s database record.
  • Every page load should verify IP matches currSessState::ulkgIP.
  • Authentication script verifies IP matches ulkgIP in the database.
  • If mismatch of IP occurs at authentication then ask both secret questions.
  • If ulkgIP_hasChanged at regular page load then re-authenticate.
  • Hidden form variables will be a secondary way of holding crsPath and crsTimestamp.
  • Every page load verifies matching session and form values for crsPath and crsTimestamp.
  • Mismatch of session and form values for crsPath and crsTimestamp result 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::sessionID matches 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.
  • The forgot.php script 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.
Advertisements

About samehramzylabib

See About on https://samehramzylabib.wordpress.com
This entry was posted in PHP Sessions Cookies and Header, Version 2.0 Site Design and tagged , , , . Bookmark the permalink.

Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s