[eluser]Stratadox[/eluser]
[quote author="WanWizard" date="1373282961"]So what makes your solution more secure?[/quote]
This solution is more secure because decrypting the cookie only gives you access to the id of the session. In the default library, decrypting the cookie gives you access to the complete content of the session: the data itself. With this expansion, the raw session data is in no way ever presented to the user, not even encrypted.
[quote author="WanWizard" date="1373282961"]It is not the encryption mechanism that is the weakness (that is published), but the key used, and if the hacker can obtain the key, the hacker can do that in both cases. [/quote]
A (determined) hacker can eventually get the key. It may require brute force, but it can be done. However, if all you win with this decryption is the session id, as is the case with this library, using that much force makes little sense. When you can potentially win access to all user accounts, as can be the case with the default library, the time spent on decrypting becomes rewarding. (And thus more likely)
[quote author="WanWizard" date="1373282961"]
You say that the session id alone is not enough to access the session. What else is required then? And is that always available? [/quote]
The session
data is valuable, the session
id in itself is nothing. The session id is also valuable, but only because it may provide access to that data.
An id alone is not enough for the
user to read or write session data - only the PHP script with access to that key gets to see the session content.
The end-users only need to deal with the outcome of that PHP script. Storing the actual raw session data on the users' machines is a pretty bad idea: it's not necessary for anything and degrades the security.
[quote author="WanWizard" date="1373282961"]
The biggest issue you have with sessions is exactly that, how do you securly tie a server side session store to a specific session? User agent is unreliable, IP address is unreliable (and can even change within a session), what else is there? Session id rotation is a commonly used mechanism to reduce the window of opportunity, but has severe issues when it comes to concurrent access, so imho not a real solution either.
[/quote]
This library provides tools for a defence-in-depth strategy; several tools are available to protect sessions from hijackers.
Sessions can be only accessed by a server-side script that has a valid session-id cookie, can decrypt that cookie and successfully validates the session. So, to break into another user's session, a hacker would have to steal their cookie and decrypt it, before the validation even begins - and even if the validation succeeds the attacker wont get the raw session content.
In comparison: if someone's cookie gets stolen and decrypted while using the default library, the thief can access the complete session data and (depending on the implementation) possibly even modify it.
[quote author="WanWizard" date="1373282961"]I understand the dependency, but my point is that the majority of CI users use CI because of it's support for legacy platforms, I think the people using it on a 5.4+ platform is a minority. Also, using it will make your application a lot less portable, because you introduce the version dependency, which will make people reluctant to use your library.[/quote]
I suppose you're right. The only dependency it has on 5.4 is replaceable for the most part by isset($_SESSION), I'll probably change that one of these days.
