Use of sessions

Any sensitive information stored in sessions should be obfuscated in some way, otherwise it is vulnerable to session hijacking.

Currently all abstract and real id's are exposed with just one attack.

It is like locking your door when you are away, your class will keep the honest people honest, but it won't stop the criminals.

So you need one additional layer where the admin can determine a salt and use that to mix up and clean up the info to and from the session.

Dave

Thank you for your suggestion, it has been implemented.
Passing a boolean true as the first parameter when initalizing the class. The second parameter is an optional salt.

However, some things to note that keep your site protected with this class even if the session is unencrypted:

Senario:
Attacker hijacks session of user $X.

*If he cannot access a vunerability that allows him to view the session:*
He can only use the abstracted ids he can find in the source as they are unguessable.

*If he is able to view all the PHP Session data through serious vulnerability in site:*
He can see all of the abstracted ids that have been defined without hunting through the source. However, without the ability to modify the session data and "register" more ids he only use the ids already registered to user $X's session. Every other user is safe.

*If they can modify the session data encryption/obfustication is just about your only hope*
However it's still a good idea for just about any case if they have ANY access to the internals of your session.

If you have any more improvments I am very open to suggestion.

Thanks Dave,
Matt

P.S. Version 2.0 Coming soon: the encryption/decryption functions will be user specifiable.

As long as the implementation passes in a unique salt and doesn't use a default specified in the class, it all looks much more secure to me.

Dave