Aventro

About the implementation of the database abstraction layer, I am just thinking freely: 1) We could have as already implemented database settings such as hostname, username, password, database and driver in the configuration files. 2) As there is similar functionality no matter what driver you use it would make sense to just provide a dns in the configuration file, and then just have one database wrapper class? Does I make any sense, do you guys agree, or how would it else why be implemented.

Well sure. I have a great codename already. After more research I simply agree with Spudinski PDO should be enabled, and if it isn't it should be possible to be enabling it, and if not, well you should consider looking for a new web host.

Why would you place the token in the url when you simply can place it in a hidden-input field on the form?

Well we can only speak for ourselves, I am however only used with web hosts/servers with pdo extensions available, and I believe yet again, enabling PDO would not harm, as it's (look again) on my link, PHP want to deprecate mysql_ but can't just do it yet due to many still using it. A good question is _ why _ ?

I believe you are wrong about the PDO reducing amount of users that can install. Since 2010 it has been encouraged to use the extensions pdo or mysqli, and they should therefore by default be enabled. I believe I haven't yet met a webhost that don't have those extensions ready to use: http://news.php.net/php.internals/53799 About Smarty, I have just used Twig (template engine, it is integrated in Symfony framework). I did indeed prefer Twig due to the escaping, the cache method etcetera. This can be discussed as well. I am also thinking about the current database structure, imo I would rather see the "character" (level, strength) etc taken out in to a new table, this way users can have many "characters/heroes" instead of one.

Done and done. I am going to let Boother make a subcategory where we can have further discussion regarding what updates Version 2.0 should have.

Already got it set up though, https://github.com/devjosmith/ezrpg

https://github.com/ircmaxell/PHP-PasswordLib is using Blowfish method. But I think we be rather off with PHPASS instead due to PasswordLib being in alpha, but we can ascertain this is nothing you want to go accomplish yourself unless you have a lot of time for it. I agree with the variable abbreviations, I'm just pointing out that there should be logical abbreviations, I didn't really look over it in ezrpg, but I just felt like naming it as it's quite an interesting point anyway.   About the mysql it would fit as for a discussion later.   I'll be setting up a Github branch asap.

Lol. xD   I can see we are rolling of the topic.

It would make more sense If you did your comparison when both the House and your site have "guests". With your logic, I believe you can see a lot of more problems with not for example locking in some valuable things when your hosting a party with people you don't know attending.

I believe there is plenty that can be rewritten or updated in the engine, and I would just like to propose some of my suggestions on what can be done. I like the engine overall, and instead of developing my own, I would rather make this one a bit up to date and perhaps a bit more active? Personally I would be glad to contribute with different modules If this could take place. Suggestions: - The password hashing sucks. First off it's using a non-iterated simple hash. Have a look here: http://stackoverflow.com/questions/4948322/fundamental-difference-between-hashing-and-encryption-algorithms/4948393#4948393 The salt is stored separetly. The salt must be unique to each and every record in order for it two work. The logical place put it is along side the password. Also it's using a pepper, which also is bad, have a look here: http://blog.ircmaxell.com/2012/04/properly-salting-passwords-case-against.html The solution is to use a library, I would recommend PHPASS (http://www.openwall.com/phpass/) or PHP-PasswordLib. (http://blog.ircmaxell.com/2012/04/introducing-passwordlib.html) I am personally using the latter in my engine. - Smarty: The current version in the engine is 2.6 or something like that, there has been a 3.0 release. An update would be appropriate. I haven't read the patch notes, but I believe it would be in our favour. - Variables expanding: This is a personal thought, but there is many people agreeing with me, I think we should expand the variables that have those random abbreviations. I believe a variable should tell exactly what it is intended for when looking at the name, therefore a quick change on the short abbreviations would be more logical and generally just looking better. - Clean the URL, Fix the MSG. The URL is messy, heavy messy. I am talking about sending the messages through the url with urlencode. Instead we should consider using like a SESSION flash message like how cakephp/codeigniter have implemented a similar functionality to provide this one-time messages. This is easy to fix. - Nice urls! Instead of index.php?mod=module&act=hello We could consider making some simple mod_rewrite and give the engine some nice urls, module_name/action etc. - reCaptcha: Instead of the custom builded captcha (more code, gd libraries(?) etc) that also requires a lot of additional code, you should consider the more developed, updated recaptcha api, it's easy as hell to integrate and is way better imo. - Clear up the code: We should remove all one-liner if statements and properly give them some brackets, there are 2 bytes extra in the line, but the code looks much cleaner and better. - Change the database abstraction layer: This could be heavily discussed but honestly, I believe there is time to update from the mysql_ functions and use PDO, we could also build a high level wrapper on the PDO and therefore keep the functionality but also increase it in speed and etcetera. Consider this post: http://webdevrefinery.com/forums/topic/1272-your-mysql-code-sucks Just a couple of suggestions after scanning through the engine, I am quite sure I could come up with more. What do you think? Would it be essential and in our favor to update this otherwise excellent engine?

I would actually not mind a CSRF token, as I can see there are no disadvantages having it, it's no big deal to implement it, and it does improve the security to your site.

I guess you have a point. However I would not rely on designing around the issue but instead just deal with it. The implementation isn't really hard. I am rather depending on a solution on the problem that have been deeply discussed around and is well used. But we all do it in different ways, if you are happy with your solution around the problem and it is prevented well then there's nothing to argue about.   Please develop your answer, I am not quite sure what you mean.

You don't make any sense. Just because the vulnerability is not a "big thing" doesn't mean it's not being used any more. They may be "out dated" but they are still possible to do. I mean If there is no big thingy how come CodeIgniter, cakephp, invisionpower and all other 'bigger' projects do take this under consideration? I would like you to consider having a look at the following articles: http://community.invisionpower.com/resources/documentation/index.html/_/developer-resources/miscellaneous-articles/protecting-against-csrf-attacks-r749 http://guides.rubyonrails.org/security.html#cross-site-request-forgery-csrf http://www.codinghorror.com/blog/2008/10/preventing-csrf-and-xsrf-attacks.html http://shiflett.org/articles/cross-site-request-forgeries

I have been scanning quickly through Ezrpg folder and could not find any token or anything that hint me on the security against CSRF. Does this mean EZRPG Project is vulnerable to CSRF? https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)