best place to store user info?

[severndigital]

I want to send some user info to the screen like first name, last name, email address, etc...

to the screen.

 

Is it secure to push something like the userid to a session or is there a more secure way store the user id, to pull the data later.

 

thanks,

C

[xyph]

Your best bet is a session. For extra security, change the session ID with each request. For ideal security, use a verified 3rd party SSL certificate, so the information is encrypted and verified. The latter costs money though.

 

Generally, the only way a session will be compromised is via hijacking. Either the user accidentally/is tricked into copying the URL containing their session ID (cookies are disabled/not implemented) or the session ID is stolen using a man-in-the-middle attack or packet sniffing.

 

Changing the ID per request will put the attacker on a clock. If the victim visits another page before teh attacker can hijack, the stolen ID is void. Also, when the hijacker steals the session, the end user will know about it immediately. If you only allow one session per user, the victim will be able to re-log in and steal the session back.

 

Hope i didn't go too deep

[severndigital]

no that was excellent information.

 

the project I am working isn't highly sensitive. But I wanted to make sure I was following some kind of best practice.

 

the user id will be used to display billing address, and invoice data. no credit cards or anything, it is mainly just for reporting to the user so they can see recent activity.

 

we may end up getting an SSL certificate, but I mostly wanted to make sure i was passing the information back and forth in a proper manner.

 

I am currently using cookies, and sessions that are logged in the database, along with IP address and whatnot.

 

my main concern was storing the user id in the session.

 

Thanks,

C

[xyph]

That's the ideal way of persisting information through multiple page requests. It's better than a cookie alone, as only the session ID is passed between the client and the server. All of the sensitive data stays server-side.

 

The only concern here is your session ID becomes the sensitive information... on the plus side the attacker should only have temporary access (assuming in order to change passwords/emails you need to confirm using the old password/email) so changes made can be fixed, especially if actions are logged. Again, if you force a new session ID with each request, and only allow a single session per user to exist, logging in again should void the hijacked session.