Welcome Guest, Not a member yet? Register   Sign In
Using session class for secure logins
#1

[eluser]tokyotech[/eluser]
Can the session class be used for secure logins? I basically just want to do the CI equivalent of $_SESSION['isLoggedIn'] = TRUE. A few unanswered questions make me uncomfortable in using it:

1. Why is it using cookies to store data?

According to the manual, it says, "the Session class stores session information for each user as serialized (and optionally encrypted) data in a cookie". Then it's not really a session; it's a cookie. What's the point of a separate cookie helper if CI sessions are just cookies? Cookies are not secure because anyone can alter them with a text editor.

2. Does it prevent session fixation?

At the PHP Security Consortium, they say that a hacker can guess another user's session ID and pass it through the URL to gain control over the user's session. They suggest session_regenerate_id() each time a does a sensitive action: login, view credit card number, etc... Does CI allow setting ?PHPSESSID=1234 in the URL?

3. Session hijacking?

Again, the PHP Security Consortium, says that you need to fingerprint each user to differentiate a victim and his attacker.

4. Session logs on shared webshosts?

I don't even have time to read about this one. There are a million other questions too. I think a framework like CI should not have me ask all these questions in the first place. It should just let me use sessions securely from the get go. The documentation says nothing about security, so I must ask anyway....
#2

[eluser]BrianDHall[/eluser]
1- Use encrypted cookies, then they are relatively secure. For real security, enable sessions in the database - no session data is then sent to the client.

2- To the last question, no - CI's library uses it's own implementation of sessions, and uses none of PHP's native session functionality. It also implements session ID regeneration for precisely this reason.

3- Actually, on the page you quote they say no such thing. They note explicitly that it could break some people's ability to use sessions due to the behavior of HTTP proxy clusters. They also note that it is merely an extra layer of inconvenience, not a de facto "you must do this for security" - it certainly isn't required for even PCI compliance when credit card data is involved.

Also, CI permits IP-locking of sessions with a simple configuration change, but again with the proviso that it will break some people's ability to use your website.

4- Session logs if used with a database are a non-issue regardless of environment, and for session logs on shared webhosts you would of course want encrypted cookies as you can never be sure someone else can't access the apache logs your website uses and/or be able to monitor headers for spying on cookie data.

For closing thoughts, security must be a question you ask of any software. CI provides a far more secure and robust solution than available in PHP itself and requires only minor configuration tweaks to use them - they aren't on by default because some people simply don't want them or have no need for them.
#3

[eluser]tokyotech[/eluser]
The manual says "If you have the encryption option enabled" and then links to the Encryption class. The encryption class is just a bunch of methods with no "turnOnSessionEncryption()" function.
#4

[eluser]FernandoMM[/eluser]
[quote author="tokyotech" date="1255742909"]The manual says "If you have the encryption option enabled" and then links to the Encryption class. The encryption class is just a bunch of methods with no "turnOnSessionEncryption()" function.[/quote]

The cookie encrypt option is actually done on your config file. Check it near session options.

But, you should really use sessions on database ( not the CI native option! Use the modified class found on the CI wiki ) or php native sessions. The CI implementation of sessions is horrible. It is extremely insecure.
#5

[eluser]jedd[/eluser]
To augment the existing comments.

0/ yes - it involves reading the manual and config files - briefly, config.php/sess_encrypt_cookie=TRUE , encryption_key={insert your random 32-char string here}, and I'd suggest sess_use_database=TRUE too.

1/ sessions can be stored in either place. I concur with the recommendation to store them in the DB, in no small part because it means you can break the 4kb limit you have with cookies.

2/ apart from anything else, CI (by default) does not respect query strings - so, yes, you are protected from the type of url you cited

3/ fingerprinting each user seems like a lot of effort, with little return - certainly it hasn't really paid off for the US gov. I suspect that if you're asking if you need to do this .. then you probably don't (or you shouldn't be designing or security auditing auth systems)

4/ if you reckon the documentation says nothing about security, I suggest you haven't really read the documentation.
#6

[eluser]Tom Schlick[/eluser]
[quote author="jedd" date="1255762588"]To augment the existing comments.

0/ yes - it involves reading the manual and config files - briefly, config.php/sess_encrypt_cookie=TRUE , encryption_key={insert your random 32-char string here}, and I'd suggest sess_use_database=TRUE too.

1/ sessions can be stored in either place. I concur with the recommendation to store them in the DB, in no small part because it means you can break the 4kb limit you have with cookies.

2/ apart from anything else, CI (by default) does not respect query strings - so, yes, you are protected from the type of url you cited

3/ fingerprinting each user seems like a lot of effort, with little return - certainly it hasn't really paid off for the US gov. I suspect that if you're asking if you need to do this .. then you probably don't (or you shouldn't be designing or security auditing auth systems)

4/ if you reckon the documentation says nothing about security, I suggest you haven't really read the documentation.[/quote]

+1 on that ... before you bitch, read the manual
#7

[eluser]tokyotech[/eluser]
Storing sessions in a database? This is outrageous. That's an additional disk access - 1,000 times slower than RAM access of a normal session variable.
#8

[eluser]Tom Schlick[/eluser]
not really considering once it is accessed it is stored in mysql's memory (ram) until it expires in which case it is just re added to the memory
#9

[eluser]jedd[/eluser]
[quote author="tokyotech" date="1255774424"]Storing sessions in a database? This is outrageous. That's an additional disk access - 1,000 times slower than RAM access of a normal session variable.[/quote]

As mentioned, it provides for session data in excess of 4KB, so the outrageous (though unsubstantiated) cost of 1000x slower performance may be worth the penalty.

Remembering that a few milliseconds is still very, very fast. And 4KB is very, very small.

Further, you're not obliged to use on-disk CI sessions. I just mentioned it was generally preferable.

Further, cookies are stored at the client end, I think. Local disk will always be faster than traversing to the client network.

Finally, in practice things are not as outrageous as you may like to believe. There are several layers of cache involved in the process - in reality it's highly unlikely that each time you retrieved some session data for your user you'd actually incur a disk access.

If you have any other misunderstandings you'd like some help with curing, let us know.
#10

[eluser]tokyotech[/eluser]
[quote author="trs21219" date="1255777774"]not really considering once it is accessed it is stored in mysql's memory (ram) until it expires in which case it is just re added to the memory[/quote]

I thought that requires Memcache. Will Apache cache database queries without Memcache?




Theme © iAndrew 2016 - Forum software by © MyBB