[eluser]ufasoli[/eluser]
[quote author="xwero" date="1196805578"]No i didn't say storing session data in a database is a bad idea. But if you have a password in the session it will get stored in the database so then there are two places where the password is stored which isn't a good idea. The more data (password in this case) gets spread around the more chance somebody could pick it up.
You can create an disposable id when a user logs in but i think if the user logs in on another place at the same time the previous id will be invalid so he can't get back to work on the other machine. If that is what you want you can do that.
But i was thinking about an extra field in the password table where you generate a steal-this-id/fake id and that id is used instead of the the real id. And you use the real id as a foreign key in tables who require it. This way you could regenerate the steal-this-id every other time for extra security.
If you don't have unique ids you could use a collection of fields that make the user identifiable without using the password. For instance if you want users to be able to log in with the same login and password but in another role (admin, author, ...) the user id and the role id makes the user unique.[/quote]
So let me see if I understand what you are saying(sorry sometimes I can be quite thick)..
I should a create a table like this for example:
Users (userid, password, lastname, firstname, id_code)
When the users logs in using his userid and password, I generate a random Id that I store in the "id_code" field and the session variable, and then use this randomly generated id as unique identifier?
Another solution could be to hash the userid field in the table, do you think this could be a good idea?
