User ID, session data and security

[eluser]WanWizard[/eluser]
I do something similar. I also generate a unique salt for every user, instead of using the same salt to hash the password.

You could extend the session class and encrypt the userdata in the session record, using the session cookie as encryption key. That way you would need the correct cookie to access the data in the session. This will add some processing overhead, so only do this it it is absolutely needed.

Given the fact that you are in control of the application code, the things to worry about when it comes to securing data are:
- can access be obtained via the frontend? Thinks about sql injections, code injections, xss, etc
- can access be obtained via the backend? Another application accessing the database? Your administrators trustworthy? Physical security? etc.

For a secure application (including private and payment data) I recently designed for a client, no secure data was stored by the application. Instead, a highly secure system was designed that stored this info, which was only accessable via a secure web service. Only non-private data could be retrieved, for example a customer could change creditcard details, but never saw the orginal number stored, only for example the last four digits. This webservice was internal, not internet facing, and protected by a web service security firewall. Also things like payment requests where send to the backend by webservice, no processing in the frontend application.

It all boils down to: how secure do you want it to be, and what are you prepaired to spent to achieve it?