Zeggy

Great, you just invalidated your own opinion as well as mine. Of course if they can get the password from the database then you're screwed. If they have access to the database, then getting a player's password isn't even needed. The point is that if somebody were to able to get a hashed password by some other means, there's no way they can do anything with it.   150 chars is a hell of a lot harder to 'guess' than 50 chars. Do you really think people sit there typing 50 characters of random strings until they get something? This stuff can be computed.  I didn't say that. But I would say a 182 char password hashed is better than 50 characters hashed. It would load a little slower?! Are you serious? Go do some benchmarking and then come reply again. I hope you know that hashing is a very common method of validating data other than passwords, and hash algorithms can be applied to huge files.   At least you admit you're not a real programmer. How do you know I'm not?  And what's wrong with that? Where do you store your single, 50 character salt then? Do you have a table in your database labeled salt, with one column and one row containing 50 characters?

Okay, 150 char salt + 32 char password = 182 chars. What's your point?  Thanks for a demonstration of hashing with a salt.  Why?  What's your point?  If you use the same salt of length 50 for everybody, IF somebody is able to match a password to a hash with a rainbow table, once that is done then everybody elses passwords can be matched even faster by using a new rainbow table which uses the salt. All it takes is one match to make your salt completely meaningless.

It is impossible to decrypt a hash... And @Crazy-T: Yes, you could write your own hash algorithm, but it is going to be nowhere near as good as SHA-1 or even MD5... Regarding the original topic: There are many ways to make your passwords more 'secure'. For example (some have already been mentioned), using different salts for each user, using multiple salts, rehashing, using more than one hash algorithm (md5+sha1?), etc. ALso, I think ImmortalThug forgot to mention - the salt needs to be a large random string. Just use some kind of string generator to generate a random string of >128 characters. If you use a salt that's 5 letters long, you're completely missing the point of using a salt :) And once you use a salt to hash a password, you must never change the salt again, otherwise you can't use the hash to verify anything anymore!

Really? What limits? I haven't met any problems developing complete games on facebook. Or were you talking about converting an existing script into one for facebook? In which case yes, if you guys are going to make a facebook app, you WILL need to code everything over again. Yes, you can accept donations on your facebook app, or get players to buy items, upgrades, premium, etc. Many facebook games do this. They also use other ways of making money, such as getting users to fill out surveys or complete 'offers', for which they get points that they can spend.

Nobody's going to want to bother filling in $minsize and $maxsize for every piece of data, especially when the size could be different on every page load (especially when dealing with user input). Your cleanIncomingData function is a bit more useful. But all it really does is just act as a wrapper to call trim and mres, with a function name which isn't much shorter than mres. Might was well give it a shorter function name so it would actually be more convenient to type. Just a note, it doesn't protect against everything. It can stop sql injections, but there are more ways of exploiting a game through mysql queries, even without ' and " (which is basically what mres escapes, as well as some other characters). For proper protection, you'll need to do real checks, and these checks WILL be different depending on the query and the data. Which means for proper security, every single query you write should also be checked in some way. There's no point relying on 'catch-all' security functions. Of course, creating some shortcut functions like cleanIncomingData would be very helpful.

COUNT is unreliable if you use the innodb engine. If you use myISAM then it should work fine. Using COUNT is generally better as it lets mysql do the counting (faster). If you use mysql_num_rows, all the rows and the row data are fetched. This would be fine if you are using that row data at the same time (such as in a member list), but if you're only looking for the number of rows, then it's a huge waste of resources. Instead, you could keep the row counts in a separate table, which is just a counter that is incremented any time you insert a row. Or just deal with the inaccuracies of COUNT. What kind of data is so important that you really need an exact count of the rows in a table?

Some ISPs allocate a single IP to all the users in an area, and they all go through the same proxy. An IP doesn't always refer to a single person, or any person at all. ALso, it's not possible to 'steal' your IP. IP spoofing is possible but not likely in this case. In a ddos, yes. In 'hacking a website', no. (That's why proxies still exist.) Now, assuming your logs are correct and the hacker used YOUR IP address, the problem most likely lies on your computer. Check it for viruses, spyware, etc., anything that could allow somebody to take over control of your computer. Then again, it could be that the hacker changed/removed the log entries that refer to him (as any good hacker would do).

If you want to be able to change 'everything', flux/open/black box would probably be better choices than gnome... What do you mean, the command line 'loads pages' faster? Do you use the command line for browsing the internet? :P

Replying to the original topic: Yes, it is possible to do that. You would probably need to write some regular expression or a script to do that for you though, it's not simply search and replace. However, securing your queries really depends on the type of query you are securing. There is no catch-all security technique to secure everything, so doing the above would be both a waste of time and counter-productive (and if done wrong, could leave your site even more vulnerable than before).

Dunno if this might help, just a result from a quick google search: http://www.codewalkers.com/c/a/Miscellaneous/Adding-Drop-Shadows-with-PHP/ Otherwise, here's how it could be done: Make a copy of the text but make it completely black (or whatever colour you want the shadow to be), and simply offset the position of the shadow text by 2 or 3 pixels underneath the original text.

It helps to protect the data in the cookie.

I really don't see how this is so complicated. Keep what I wrote in the previous posts in mind, I'll explain the login side a bit more: index.php: $r=$db->Execute("SELECT ID,PASSWORD,AUTHORIZED,SALT FROM PLAYERS WHERE USERNAME = ".$db->qstr(strip($_POST["USERNAME"]))); if($r->EOF || md5(md5($r->fields[1].$_SERVER["REMOTE_ADDR"]).$r->fields[3] != md5(strip($_POST["PASSWORD"]).$r->fields[3])) Really, that's it. There's simply a salt added onto the hashes on both sides of the comparison, and the result of this hash is stored in the cookie. setcookie("ZAPLOGIN",$r->fields[0]."/".md5(strip($_POST["PASSWORD"]).$r->fields[3]));

Yes, I know how it currently works. So, the user logs in and sends md5(md5(password)+ip). On the server side, you receive this hash and then hash it again, this time with a salt. the end result is md5(md5(md5(password)+ip)+salt), where the salt part is done on the server side while the rest is done through javascript. Uses a salt, and password is never sent in plaintext. Simple :)

Hmmm, yeah, you're right about storing the time in the cookie. Using the salt: Okay, you send the hash ($userhash) that you currently have. What's sent over the network doesn't change. On the server side when you are checking if the username/password is correct, first concat the hash with the salt, which could be unique to the game, or even unique to the player if you want (md5($userhash . $salt)). If you want a unique salt for each game, just generate one during the install process. If you want a unique salt for each player, generate one during the registration process, and when you are checking the login, just fetch the salt together with the id/username/password. The salt is never transmitted over the network, only the result of md5(some_string + salt). If somebody were to have a user's id, password hash (sent over the network) and IP, all that data would be meaningless since it would be near impossible for them to break the hash or generate a new one without having access to the game config (access to the file system) or access to the database, depending on where you store the salt(s), in which case your game will be screwed anyways :)

You could save the time that the user logged in at, then check how much time has passed since the first login. That way you can also put it in the admin options/config where the admin can set how long users can stay logged in for. (Or even let users choose how long to stay logged in) The token method would work too, but if you do that you might as well just use sessions (right?). What do you mean, when you transmit it? I said that if you add a salt, then it won't be possible to use a rainbow table. Yes, it's just a game. Since you are leading the project you can decide what level of security you want to offer the users of zap engine. Personally, I'd try to do the security as well as I can, since there's always loads of people accusing each other of how 'insecure' each others' scripts are. Clearly users are paranoid about security, whether or not they really need it.

I think the current login process could be improved a bit. A cookie stealer could get entry to an account as the cookie doesn't seem to have an expiration time on both the front and back end. I see that the cookie does use IP to verify the user but if somebody were to steal a player's cookie, getting their IP would also not be a problem. You could encrypt the cookie data (or make a hash of it), and include some kind of expiry timestamp, so that even if somebody's cookie was stolen, the hijacker only has a limited window of opportunity. Also add a salt to the hash on the server side after the user submits the login form. You could generate this salt during the installation process, so that every game using zap engine will have a unique salt. That way, even if the cookie stealer has the player's cookie and IP address, it would be far too impractical to try and generate a rainbow table to guess the player's password.

Don't worry, you can ignore my suggestion of using arrays instead of serialization. As you pointed out, I misread the function :)

I use openbox. It's very nice :)

world.php: Fatal error: Call to a member function Close() on a non-object in C:\wamp\www\zap\zap_engine\libs\misc_util.php on line 374 I was on revision 43, then updated my files to the latest version with the energy restoration code. I believe the database structure changed and this error is because the database is out of sync. If anybody else is having this problem, delete work/installed_modules.db and re-run the installer to update your database. This will delete all previous data. This is just for the people who are developing the game or testing it through SVN. By the way: whats the difference between zap engine and mwg engine?

Ah, okay, you're right, I missed that it was a global variable. I wouldn't say editing a serialized string is easy though. You'd need to update character counts for individual strings and update element counts for the whole array. It would be far too impractical to try editing it by hand rather than through the admin panel.

I have some changes to propose: Upgrade to xhtml? I recommend not using serialize for localization. At first I thought you would have to unserialize all language strings on each page load. But looking at your t() function, it's even worse - you unserialize strings on demand. If a page has 50 calls to t(), you are unserializing the entire language file 50 times! If you stored the entire thing as an array instead, you could load it once on each page load. If you stored it as a PHP array, it would also be just as easy to edit from the admin panel as it is to edit the plaintext file by hand (which for some people is easier - you can also run automated scripts for quick translations to new langauges, or a quick fix). I don't have much free time at the moment so I haven't had a chance to take a deeper look at the code but it looks pretty good so far :)

I would recommend generating the basic maps (static terrain, terrain details, etc) as a single image on the server side, then caching them. Then use CSS positioning to add anything that changes (eg. actors, objects, items). This way you only need to load a single image for the tiled world without having to generate anything on the fly or loading a bunch of terrain images at once.

I've only used java for desktop/mobile applications, not jsp or applets. Personally, I think it's far too verbose. :P But apart from that, I don't really have any problems with it.

Re: Database class for PHP 5+ and MySQL (Help) Put doDisconnect into the __destruct function.

Re: My PHP Tactical RPG Game Engine lol, I know you're basing your engine off the flash game, but are you sure that image is actually a screenshot of your game? It looks a bit too much like the flash game :)