Quote:Original post by AndreTheGiant
Im just beginning with PHP so this topic is pretty interesting to me. Forgive me if this is naive, but what is wrong with the following security model:


1) On the login page, gather their username and password.
2) Compare these with the USERPASS table in the database.
3) If the login is valid, generate a Big Random String (BRS) and store it in the SESSION table in the database. Also return the BRS to the login page.
4) For every secure page on your site, check that the BRS (passed on GET or POST) is in the SESSION table. If it is, you know its a valid user.
5) When the user logs out, or times out or whatever, remove the BRS from the SESSION table.

This doesnt use Cookies, or the Session PHP utility, but It does of course use mySQL.

Comments?

You just described how PHP sessions work when cookies aren't enabled in the browser :D
... with some minor differences: sessions are stored in a file on disk and not a db table and php takes care of rewriting the links to include that BRS (your BRS is called "session id" actually).

Also, there are several (minor) problems with the approach:
1. passing around session id ("brs") via get: depends on "how big your brs really is"
2. some user can copy+paste a link (which includes the "brs" if you pass around via get) and send it to someone and then that second person would be automatically loggged-in via the first users' account
3. BIG performance issues with storing session in mysql! ok, on a personal website with 50 hits/day is no problem, but if your site has lots of visitor, every page view means a select AND an update to the same table. And the wonderfull mysql uses table-locks (at least with MyISAM) so the site will be slow and painfull.

basically, there's nothing 'badly wrong' with the model you described... that's why php uses same model (or almost the same).. but I would recommend trusting the php session code (you can write your own session handlers and still let php taking care of cleaning old sessions and generating sessions id's), it has been tested intesively by lots of sites :)

Quote:Original post by cobru

Quote:Original post by AndreTheGiant
Im just beginning with PHP so this topic is pretty interesting to me. Forgive me if this is naive, but what is wrong with the following security model:


1) On the login page, gather their username and password.
2) Compare these with the USERPASS table in the database.
3) If the login is valid, generate a Big Random String (BRS) and store it in the SESSION table in the database. Also return the BRS to the login page.
4) For every secure page on your site, check that the BRS (passed on GET or POST) is in the SESSION table. If it is, you know its a valid user.
5) When the user logs out, or times out or whatever, remove the BRS from the SESSION table.

This doesnt use Cookies, or the Session PHP utility, but It does of course use mySQL.

Comments?

You just described how PHP sessions work when cookies aren't enabled in the browser :D
... with some minor differences: sessions are stored in a file on disk and not a db table and php takes care of rewriting the links to include that BRS (your BRS is called "session id" actually).

Also, there are several (minor) problems with the approach:
1. passing around session id ("brs") via get: depends on "how big your brs really is"
2. some user can copy+paste a link (which includes the "brs" if you pass around via get) and send it to someone and then that second person would be automatically loggged-in via the first users' account
3. BIG performance issues with storing session in mysql! ok, on a personal website with 50 hits/day is no problem, but if your site has lots of visitor, every page view means a select AND an update to the same table. And the wonderfull mysql uses table-locks (at least with MyISAM) so the site will be slow and painfull.

basically, there's nothing 'badly wrong' with the model you described... that's why php uses same model (or almost the same).. but I would recommend trusting the php session code (you can write your own session handlers and still let php taking care of cleaning old sessions and generating sessions id's), it has been tested intesively by lots of sites :)

1. I guess I would have to keep the BRS under 1024 characters, or whatever is supported on the GET string. Which is still more than enough to still be secure right? Either that or use the POST method which is probably what I would do anyway.

2. I dont care. If a user wants to let someone else log in to their account,they could just as easily give that person their password, as the BRS right? Am I missing something here? Also, using POST would get around this problem as well.

3. Did not know that. For the time being however I think Im safe ;)

Thanks a lot for the advice, and the quick response!
So basically I should use php's Session support since it basically does what I desribed, only is already written for me, and probably has some other nice features I havnt thougth of.

Thanks!

Sander >> Thanks for the info - I just implemented it.