| 3:51 am on Apr 9, 2009 (gmt 0)|
|Do I encrypt a variable in the session/cookie? |
Session variables aren't visible to the outside world so what would encrypting it do for you? You'd just have to decrypt it.
Might be simpler just to store the user id. If you have one, then the user is logged in.
| 4:20 am on Apr 9, 2009 (gmt 0)|
The system itself is a little out of date, but the ideas behind it are still great. Like eeek said, session vars are not visible to the outside world, and thus can't be manipulated by anyone but the server(that I know of).
| 1:09 pm on Apr 9, 2009 (gmt 0)|
A session may be stolen; you need to make sure that the expected session is the one that is passed
G for “stealing session” “securing session” etc…
| 6:45 pm on Apr 9, 2009 (gmt 0)|
Thanks all :)
henry0 I did see people mentioning that, and I think that is where the confusion came from.
Can anyone give me some more info on what to do with the cookie. Do I store the visitors username/password (encrypted) in the cookie and check are authorised at the start of each session, then hold that variable "Y/N" in the session?
| 7:18 pm on Apr 9, 2009 (gmt 0)|
That's a different issue. If it's a big concern, you need to use SSL.
|Can anyone give me some more info on what to do with the cookie |
Use PHP's sessions feature and don't worry about cookies.
| 9:50 pm on Apr 9, 2009 (gmt 0)|
in such a case SSL might not be required
but the usual checking more than ever
for example don't even trust yourself!
say you pass a session with a content of AAA
the receiving page/pages ought to check if the session only contains uppercase alpha char
| 11:21 am on Apr 10, 2009 (gmt 0)|
In the cookie / session (whatever you're using, maybe both), store the user id and a message digest of their password, e.g. md5($password). Then validate what the user presents against the database. Passwords shouldn't be stored in plain-text in your database.