Accessibility of session data

[jamest827]

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

[Newsgroup_User · Accepted solution]

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.

[jamest827]

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

[Newsgroup_User]

"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.

[jamest827]

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