everythingis wrote:On both my Register & Login scripts, should I remove both the stripslashes() and striptags ()? Or just the stripslashes?
In my opinion, data should be stored in the database without disrupting it's integrity; thinks such as [man]strip_tags/man, [man]htmlentities/man, etc. etc. should only be used (if necessary) when displaying data retrieved from a database - not when inserting it.
As I've said before (if not here then I'll say it now :p), you should never have to use [man]stripslashes/man on incoming data with one exception: to reverse the affects of magic_quotes_gpc if it is enabled (in which case, you usually walk through the $POST, $COOKIE, and $_GET arrays before you do any other processing to undo the ill effects of magic_quotes_gpc).
everythingis wrote:I'm guessing the reason why I'm not supposed to use mysql_escape_string for it when I set the md5 (and I'll add hashing & salt), is because it's safe regardless what the user inputs because it will be randomized into an alphanumeric value?
Well it won't be random, but yes, the output of the MD5 algorithm will be a hexadecimal string. Since none of those characters ([0-9a-f]) will cause problems in a SQL query, there's no need to escape the data. It certainly doesn't hurt to try to escape the output of an MD5 hash, but it's a bit of a waste of time (since nothing will be escaped).
everythingis wrote:Oh, and on my login page, am I setting the sessions and cookies correctly?
Nothing seems wrong, although when using cookies I like to specify the domain as ".mydomain.com" so that the cookie will be sent for both http://mysite.com and http://www.mysite.com. By default, it will only apply to the domain the user visited, so if you redirect them (or they later type in the other URL) and the subdomains don't match (e.g. going from a null subdomain to "www" or vise versa), they'll be "logged out" since the cookie won't be sent.
As an example, look at how you're accessing PHPBuilder right now. If it's "www.phpbuilder.com", and you've always visited the site that way, try removing the "www." from the URL - you'll probably have to login again (or go back to "www.").
One problem I do notice is that you never call [man]session_start/man on the login page, thus session variables won't be available.
everythingis wrote:Do I need to randomize those, or is it not necessary?
Don't know what you're referring to... randomize what? The values? The names? I can't think of anything you'd need to "randomize," so I guess the answer is... no?
everythingis wrote:And is setting a cookie for the password safe, or should I remove that one?
If you removed the password from the cookie, how would you authenticate returning visitors? Solely by the username in the cookie? What if I altered the headers my browser was sending and used different usernames?
For sensitive data like that, I like to use sessions so that the data is server-side only. Because of this, the user can't maliciously tamper with (or even see) the data. You can always modify the session cookie to persist longer than the current session by using [man]session_set_cookie_params/man. You might even use [man]session_name/man to give the session a unique name so that other scripts won't disrupt the session.