Authentication and Sessions

[eluser]Michael Wales[/eluser]

using db for ci session does have it’s pro & cons but NOT in the case where you’re using it for authenication imo. There’s no option you have to use db. don’t store anything in a cookie seriously just store it in the database. cookie is just there to say you own this session in db. there’s no security w/o db.

I definitely agree but as library authors we have to assume the worst.

i mean hell~ i wont even store it with some encrypted hash… someone might figure out how you’re hashing it and there goes security. and isn’t that still vulnerable to spoofing and session fixation?! even though you can’t edit the id because you can’t guess the ash?

Remember the difference between encrypting and hashing - hashing is one way. Sure, a rainbow table is going to find the hash for integers pretty quick, but it would take quite awhile for a rainbow table to find the hash for an unknown combination of data (let's say, a concatenation of the user's salt, username, password, and timestamp of record creation). That's where the true security lies in this - you grab their ID and token (the concatenation hash), select on the DB, hash their record and see if it matches the token. If not, something has been tampered with.

Wow but it looks like alot of other auth libraries also didn’t consider the fact that a programmer might have his ci session setting not using db.

Yeah, I'm usually over-careful with working with sessions because I remember CodeIgniter when it didn't store custom userdata in the database. You could turn on database storage but it only stored the standard fields in there, all custom data remained in the cookie.