4 Replies Latest reply on Oct 30, 2007 12:56 PM by jamest827

    Accessibility of session data

    jamest827 Level 1
      I'm thinking of a password reset scheme using a user's email address to authenticate the user's identity. My code would generate a random string, send it to their email address (already stored in my application's database), then require them to enter that string on a form.

      Between displaying this form and receiving the user's form submission, I'm considering keeping this string in a session variable. My question is, is there any way for a user (web client) to get at the session data? Are there CF administrator settings that would make the session data more secure (other than the obvious one of not having debugging enabled)?

      This will be on CF MX7.

      Thanks for any insights,
      James
        • 1. Re: Accessibility of session data
          Level 7
          Session data lives in the RAM memory of the ColdFusion server. There is
          not direct way for a client machine to access this memory. The hacker
          would have to have access to the ColdFusion server machine or code on
          that machine that interfaces with the session data.

          That being said, sessions are spoofable. The only way the web server
          knows what client belongs to a set of session data is through the cfide
          and cftoken cookies. If a client request provides the correct
          combination of cfide and cftoken values it will be associated with that
          session data.

          Finally, if you send a user a link with a random value to validate them,
          they may not do it right away in the same browser from the same computer
          that they were using. Any of these factors and more will cause them to
          have a different session then the original request came from.
          • 2. Re: Accessibility of session data
            jamest827 Level 1
            Thanks, Ian, that's pretty much what I wanted to hear. Your final remarks are exactly why I like using a session variable for this; the random code has to be used then and there, and does no good to someone pulling a printed email message out of a trash can (for example).

            As for sessions being spoofable, I suppose that's a weakness of the whole idea of using a session variable to represent a logged-in state.

            Thanks,
            James
            • 3. Re: Accessibility of session data
              Level 7
              "Your final remarks are exactly why I like using a session variable for
              this; the random code has to be used then and there, and does no good to
              someone pulling a printed email message out of a trash can (for example)."


              Depending on how wide an audience this is being targeted to -- all
              clients may not be able to respond "then and there". Emails can be
              delayed for any number of reasons. A user may close the browser and not
              check their e-mail for more then 20 minutes, maybe even a day or two,
              later. They may sign up from a work or library computer and respond to
              the e-mail from home or a different computer.

              As stated, a lot of this depends on intended audience.

              The usually practice is to make sure each code is one use only. Once it
              has been verified it is no longer valid and if anybody else tries to use
              the code it will fail.
              • 4. Re: Accessibility of session data
                jamest827 Level 1
                Ian, thanks again for your input. The one-use approach certainly makes sense, though I'd want to attach a timeout period to that as well. For my purposes, I still like the response required in the same session; the user can always make a request for a new auth code when they have access to email. Anyway, I'll see how it flies, and keep your plan in the wings in case it doesn't work out.

                James