Rushyo

"http://twistablepie.servegame.com/cype/?cype=main&page=ranking&order=name" Allows me to check existence of field names for that table. There seems to be quite a few holes in GET data filtering.

active.php is always returning "There was an error in the activation of your account. Please email the site admin and describe your problem" even with valid credentials.

Initial observation: $EnemyDamage3= round($EnemyDamage3 / 1.25); Since you set EnemyDamage3 to 0 when there's insufficient Chakra, you're going to cause a division by zero. Honestly, I'd be surprised if anyone has time to dig through all that code. Have you tried a 'dry run'? You will probably find any bug quicker than we will.

http://www.phpfreaks.com/forums/index.php/topic,232470.0.html The big sticky at the top of the forum. I just tried using your site in a normal capacity with only slightly anomalous results and it seems very eager to throw up internal server errors.

An echo replaces a statement with whatever it returns... thus: <td colspan = "5"><input type="text" name="DESCRIPTION" value="<?php echo "{$row['DESCRIPTION']}"; ?>"id="DESCRIPTION" size="100" /></td> Will return: <td colspan = "5"><input type="text" name="DESCRIPTION" value="14""id="DESCRIPTION" size="100" /></td> Not terribly correct HTML. You should use encoded characters, see http://uk.php.net/html_entities. For example: $strDesc = html_entities($row['DESCRIPTION'], ENT_QUOTES); The ENT_QUOTES is important, otherwise quotes won't be converted

By default, div tags are block elements. Thus they always reside on their own line. Why do you need them in divs? Would a span not suffice?

"md5 hash ur cookie variables" Unsalted it wouldn't offer any viable protection as is, since the user could just md5 the username he wanted. admin -> 21232f297a57a5a743894a0e4a801fc3

mysqli_real_escape_string() will work for most purposes.

if ($_POST['password1'] != $_POST['password2']) { die ('Your Passwords Do Not Match. Please go back and try again. Thank You.'); } die() ends execution. Hence it would never get to the include() statements.

As the errors state: Failed opening 'config.php' for inclusion Failed opening 'opendb.php' for inclusion These files either do not exist on the server or your server does not had read access to them.

The PEAR library has a mail function which is quite powerful.

"also can someone tell me how i would achieve gettings the users ip logged each time the User Account logs into the system? please and thanks" <?php $strIP = $_SERVER["REMOTE_ADDR"]; ?> Then just put $strIP in your database. Note that this value is pretty easily faked.

Eight characters and 'easy to remember' are not mutually exclusive. Regardless... if the user wants to stick their password up, that is generally their problem rather than yours. If the user's password gets stolen because somebody brute forced your website though, they'll tend to hold you responsible for it regardless of the merit of the argument. It doesn't make more than a negligible difference in the context it is being suggested.

"i set max characters to 50 and everything works now... thanks.... now what else could i do to make the names and passwords more secure??? " MD5 hashes are always 32 characters long. Ideally, you should use SHA256 rather than MD5. They're not hugely different, but the former is certainly more secure. You should create a very long string to use as a key and add that key to the end of all passwords. You should also create something unique for that account (preferably based on as many factors as possible such as time, the user's IP, and other things.. the more random the better) and add that, also hashed, to the database alongside the password. So it'd be like this: <?php $strLongKey = "uihf4ef...adoijwudn;" //This can be anything, feel free to type it by hammering the keyboard... the longer the better. $strSalt = sha256(time()); //This just uses the current time... add more variable stuff here to increase entropy! $strPassword = sha256($strSalt.$_POST['pass'].$strLongKey); //Do stuff mysql_query("INSERT INTO users (username, password, salt) VALUES ($strUsername, $strPassword, $strSalt"); ?> To login, repeat this procedure but instead of generating a new random salt, get it from the database. The key must be the same each time. Now someone who breaks into your database won't have the key... and someone who breaks into your application won't have the salt. Bearing in mind this is just password salting alone. Password constraints (minimum 8 characters, using a range of characters) is very important as well. To make a secure application requires significant expertise. Most companies will hire a professional to audit and/or certify their systems.

As I asked earlier: Are you sure the $_POST vars are getting through to the script fine? Try echoing your SQL statements to check what hash is actually getting through.