Native sessions or CI sessions.

[eluser]WanWizard[/eluser]
You're not getting the point.

How do 99,9999% of the applications use a session:
- user goes to website, enters as guest/unauthencated user
- user goes to a login page (most of them not encrypted btw)
- user types in userid and password, and clicks submit
- application validates the credentials
- if valid, an 'id-value' is stored in the session linking the session to the user
- session cookie containing the session id is sent to the browser

When the user requests an other page on that same site
- browser sents cookie to the application
- application extracts the session id and loads the session data
- application checks if a valid 'id-value' is present in the session data
- if present, the link to the user is looked up
- application sends the result back, with the user as being logged in

Where in the second step of this process is there any user interaction? Nowhere. There is no password check there. And I'm willing to bet that your applications aren't any different. This is what sessions do: maintain state.
So if I can get hold of that cookie, and there is no mechanism to make sure I can't use that cookie, I can hijack your session.

Now, as I already said, if you're talking about CI's implementation or the alternative libraries floating around that are based on CI's implementation (note that the "CI Native Session library" is NOT the same as PHP native sessions, and that is what started the discussion!), the cookie hijacking issue is mitigated due to the extra checks introduced by the library (IP & agent checks, and a rotating ID which limits the lifetime of the stolen cookie).

As far a speed is concerned, the impact of reading one record and writing one record per page request is virtually nothing compared to all other I/O generated by the application. It will probably never be as fast as direct disk I/O (unless your RDMBS has the table cached), but the benefits of having the data in the database more than outweigh the extra cost involved (backup/restore, load balancing, offloading or multi-tier solutions, easy application access to session data (ever tried to determine the number of logged in user with native session files?), etc). Something that is very clear in any business context. And furthermore, hardware and processing power is dirt cheap, and therefore no factor in the discussion.

However, the cost and impact of a security breach for any company can shoot up a mile high before you know it. And, as said, if speed is a real consideration, use memcached backed sessions. All the speed, none of the security risks.

People that worry about these trivial things are those who decide to host their websites at the GoDaddy's of this world. Which imho says enough...