What data is used to make the hash for sbbsession?
Oh, and storing the user ID/username (either) is pointless or insecure. All you should need is a hash of the user+pass, (such as sbbsession, maybe). Nobody can crack that without knowing the user+pass, and they wouldn't need to if they did. It's simple.......... SO SIMPLE!
In fact, wait... Even That's redundant- to a point. You don't even need to hash the user+pass... Look, try a procedure more like this: [It's taboo to store raw password data in cookies, but someone actually has to steal their cookies for the particular site in order to get it. If a user is
that insecure, technically they shouldn't be ENTERING a password in the first place.]
Code:
- User enters site.
- If Session[user] & Cookie[pass] are defined
- - continue
- else :
- - If Post[user] & Post[pass] are defined
- - - Cookie[user] = Post[user]
- - - Cookie[pass] = Post[pass]
- - If Cookie[user] & Cookie[pass] are defined
- - - Session[user] = sql_escape(Cookie[user])
- - - Session[pass] = md5(Cookie[pass])
- check_user_data(Session[user],Session[pass])
check_user_data returns the number of rows for a query that selects an id from the users table where user+pass are equal to their alter-ego session values.
If true, the user is seen as logged in. False, they are not logged in as anyone. No silly "Ah, being hacked!" messages, they're just immature. Also, there's no purpose for those lines in any application that doesn't expect to be getting hacked.
Since the cookies+session values are always the same (this should be declared at the top of all pages), then you only need to check the one with highest priority. Cookies are optional, if the user ticks the box that says "Remember Me", then they get a couple extra cookies, otherwise they only get the PHPSessID cookie.
The purpose of the cookies are solely for keeping a user logged in after the session is over. So if they visit your site with cookie variables, then they get turned into session variables, and cookies are never heard from again until the next time a session is created. That's why I chose to make them literally, identical of the form variables submitted.
If for whatever reason you change the way you encrypt the password or whatever, people who come back with user+pass cookies won't notice any problems, because the user+pass are compliant with the log-in form, and everything gets turned into Session[name]. All you'd have to change is the session variables, because they're the most reliable, and will surely have the data we need, whenever present. That data will come from the client [as GET, POST, or COOKIE]. But it will be escaped, in it's own way, before being compared with/inserted to the database in the form of a query.
Security is a breeze, just recognize every single point that makes a program insecure- that is, wherever the client can manipulate (or even view in some cases) ANY data on your server.
