Jump to content
Sign in to follow this  
Spudinski

Our ezRPG 2.0

Recommended Posts

Hello people,

You've probably heard or seen that another version of ezRPG is being created.

I'm here to tell you about the plans for it for two reasons:

1. I call on other developers to join in, and,

2. Raise awareness in an attempt to get suggestions and feedback.

Without further adue, let me tell you what's been done so far, and what is currently planned for the road ahead.

As discusses previously on this forum, a better password hashing method was *needed*.

Me and Aventro(on here), couldn't decide which algorithm to use since we had different opinions on the matter.

Because of that, ezRPG 2.0 will feature two unique hashing algorithms: PBKDF2 and bcrypt.

The engine will eventually have an option during installation(and afterwards configuration) to choose which one you would like to use.

The issue can be viewed here: https://github.com/nands/ezrpg/issues/1

Next, the database adapter was quite foobar in my eyes.

An additional mysqli adapter is now also present, and there's plans for a PDO adapter.

There's currently no plans to rewrite the database library itself, since it's been updated recently to implement the adapters with a more appropriate method.

You can view the issue here: https://github.com/nands/ezrpg/issues/4

Last but not least, Aventro has updated the validation library.

Email validation is now done in a much more bullet-proof way, using filter_validate_email, or filter_var for short.

Issue can be seen here: https://github.com/nands/ezrpg/issues/2

There's quite a few more things that has been done, so I encourage you to come take a look at either https://github.com/devjosmith/ezrpg or https://github.com/nands/ezrpg.

I'd love for you all to join us in our conversation and make suggestions, or even lend a helping hand.

Thanks!

S.

Edited by Spudinski

Share this post


Link to post
Share on other sites

Yes, anyone who would like to contribute, be sure to make so! We want to develop and improve the ezRPG due to the potential it actually has!

If you're not sure in what way you can help out, just ask!

Share this post


Link to post
Share on other sites

Stupid question, but I have read alot about different hashs around the forum but what exactly is wrong with sha or use something like vbulletin does?

Share this post


Link to post
Share on other sites
Stupid question, but I have read alot about different hashs around the forum but what exactly is wrong with sha or use something like vbulletin does?

"Its the end of the world as we know it"

(just in case you wonder why the above answer, quoting yourself: "Stupid questions" demand stupid answers)

Share this post


Link to post
Share on other sites
"Its the end of the world as we know it"

(just in case you wonder why the above answer, quoting yourself: "Stupid questions" demand stupid answers)

Your soooo funny.....

Share this post


Link to post
Share on other sites

 

If you have plans to fork ezRPG, that is fine, but at least don't call it ezRPG as it is clearly not an official update. especially calling it ezRPG version 2..

I agree.

Using a codename, and only referencing to ezRPG would be much better.

Was this part abandoned or...?

Share this post


Link to post
Share on other sites
Was this part abandoned or...?

There is a code-name, ezRPG rework.

But, since you haven't responded or rejected my queries as of yet, your implication is that it is *fine* by you.

If you're not happy with it, please reply to my message to you wherein you state so.

@Ian: I'm not going to explain the reasons why, please refer to Google.

Share this post


Link to post
Share on other sites

Sorry, i didn't notice your PM. for some reason it never showed a notification for it, only notification i've seen recently was a PM from ColdBlooded. I will reply to it ASAP

Share this post


Link to post
Share on other sites

A few changes were made, I'm just going to explain the most major ones here.

Password hashing algorithms: bcrypt, PBKDF2 and Oldschool

We have implemented a security lib just for this, under lib/func.security.php.

There's also a configuration flag within the configuration file that is used system wide.

So, why spend all this time on something like this?

I personally feel that one has to be "creepily obsessed" with security, but not in a way that an application is fort-nox with no windows.

These changes will improve security not only per user, but also per engine(exception bcrypt, which doesn't support multiple hashes).

Each user's password has three key parts as the engine sees it: the actual plain-text password, the player specific salt and the global salt as defined within the configuration file.

PBKDF2 and bcrypt is also somewhat more secure than legacy sha1+salt methods, as each calculation of a hash takes time.

This means that, users will see a short delay when hashes are calculated(about 0.2 - 1.5s) which isn't anything really, but for brute-force attackers this is a big problem. Even if they have any part of the hash(password, user salt or global salt), it will still take plenty of time to crack the actual password. The biggest flaw here is the webmaster: if they're not using SSL passwords are still sent in plain-text.

So which one should you use? It's for you to decide, but here are the facts..

NIST recommends PBKDF2.

Most people prefer bcrypt.

Don't use Oldschool unless you need compatibility with older versions.

Improved signatures

A signature is much like a "key". The user carries one, and sends it to the server on every request(done with SESSIONs in ezRPG).

Every time a user makes a subsequent request, the server calculates a signature of that request - if it matches the one the user carries, authorization is granted to the system.

ezRPG rework improved this a little bit.

A signature tool set was added to lib.security, and uses four unique data sets: userid(guest if not logged in), IP address, browser details and engine key/salt. Using the IP address is a harsh decision, but it's one of the data sets that is the most static and individually identifiable.

Added session expiration

You might have seen this on quite a few sites - if you're inactive on the website for a few minutes, it prompts for your password again to be able to continue.

Why is this needed?

There are many ways in which sessions can be stolen, XSS being most predominant.

This is a tough one to secure against, but with the signature and this feature, it is handled well.

Even if it's a less malicious attack, like you leaving the tab open and someone comes in to attempt to do something. If the timeout is hit, the user must enter a password to continue - or alternatively, they can log out.

"Proper" UTF-8 support

Normal ezRPG used HTMLpurifier to attempt and encode any random output PHP produces into UTF-8.

This doesn't really make sense, since the original character set is rather unknown.

We've implemented something simple: setting PHP encoding and output encoding.

This works, but some string operations with database content will have to be rewritten to support multi-byte character sequences(and we'd need to drop ext/mysql in all).

A later feature might be to include gzip compression as well.

 

So that's the most major things that changed, any comments welcomed.

Share this post


Link to post
Share on other sites

Will you be able to adjust the session expiration? I can see why your doing it but i can see it being a real pain in the backside for the end user if its too short. Things like this annoy me if I cannot alter it.

gzip compression. Most hosts activate it as standard which is good practice as it saves resources. Depending on your compression method it may serve to be incompatible. There are still hosts using less favored methods. Or would this be a cache type compression of say css, js etc.

Proper UTF-8 support. I recently had a major headache with dealing with utf-8 but then also having to accommodate special characters from countries such as Finland, Sweden have you taken this into consideration?

Is there a need for guest signatures?

Share this post


Link to post
Share on other sites
Will you be able to adjust the session expiration? I can see why your doing it but i can see it being a real pain in the backside for the end user if its too short. Things like this annoy me if I cannot alter it.

gzip compression. Most hosts activate it as standard which is good practice as it saves resources. Depending on your compression method it may serve to be incompatible. There are still hosts using less favored methods. Or would this be a cache type compression of say css, js etc.

Proper UTF-8 support. I recently had a major headache with dealing with utf-8 but then also having to accommodate special characters from countries such as Finland, Sweden have you taken this into consideration?

Is there a need for guest signatures?

Thanks for the Q's.

Session expiration:

There are tow things that will play part in this - PHP's session timeout settings, and the engine's.

PHP's is 24 minutes, or 14400 seconds - this can easily be modified though.

There should be a way of changing the session expiration timeout, I didn't really follow the schematics there - it's currently 5 minutes.

Edit: Ok, seems like a useful feature - added. see #d0cbbe5. Thanks rulerofzu.

gzip compression:

Stylesheets and others are automatically gzip'd when it's enabled(on apache/php conf).

And no, it would cause problems when the script handles the output buffering - it's just setting values already available.

That's why I chose UTF-8, and why I said we'd need to rewrite string operations with mb_*.

But yes, I know, dealing with character encodings is an art! (not really, you just have to know the principles, and have an ASCII table ready).

Guest signatures:

Well, kind of.

The functionality is available, but not in use.

Signatures are only implemented for authenticated players.

Edited by Spudinski
d0cbbe5

Share this post


Link to post
Share on other sites

One thing that I do find puzzling is the password hashing

It was one thing how you both could not agree so have included a choice but Oldschool for backwards compatibility I assume with the current engine? As far as I know its a rather unused engine where at most it has been dabbled with.

I would have thought you would be better just ditching the oldschool or at least keeping it for a one time login now set a new password into the chosen new hash for anyone transferring from the current engine.

Seems to me by the way of giving the option of oldschool that your defeating your own objectives.

Share this post


Link to post
Share on other sites
Nice additions, even if it's mainly only security improvements. So congratz for the release.

The first steps is to make sure the engine is secure from the point where we take off, I believe like Spudinski probably agreed with me that security measures is all of importance, there is no reason taking further steps, if the engine is inreliable. :)

 

Great job Spudinski!

Share this post


Link to post
Share on other sites
One thing that I do find puzzling is the password hashing

It was one thing how you both could not agree so have included a choice but Oldschool for backwards compatibility I assume with the current engine? As far as I know its a rather unused engine where at most it has been dabbled with.

I would have thought you would be better just ditching the oldschool or at least keeping it for a one time login now set a new password into the chosen new hash for anyone transferring from the current engine.

Seems to me by the way of giving the option of oldschool that your defeating your own objectives.

Well, there might still be people that have a special need for it.

sha1 + salt isn't totally insecure, as said, it's just not "the best possible security available for dealing with password authentication".

It has been disabled within the new installer:

[ATTACH=CONFIG]641[/ATTACH]

@a_b & @Aventro: Thanks. :)

Untitled.png.34bd82f973155ed9c40a3c1fb86c8172.png

Share this post


Link to post
Share on other sites

Hello, just want to tell you that i am glad i found out you guys working on improving this project. And i like direction you heading.

Lots of stuff seems very helpfull. Now there is only question how easily i will be able to include this to existing project which looks very different from original ezrpg1. Will give it a try for sure.

Share this post


Link to post
Share on other sites
Hello, just want to tell you that i am glad i found out you guys working on improving this project. And i like direction you heading.

Lots of stuff seems very helpfull. Now there is only question how easily i will be able to include this to existing project which looks very different from original ezrpg1. Will give it a try for sure.

Thanks. :)

All modules that work on ezRPG original will work on ezRPG rework.

Share this post


Link to post
Share on other sites

Updates again...

GET_MSG

This method of sending messages between requests have been removed.

It contained a very serious XSS vulnerability:

Something like "index.php?msg=<script>alert(document.cookie);</script>" would have been valid.

A method have been added to the Base_Module class just for setting messages: setMessage(string message, string level).

There are three levels to make use of: info, warn, fail and good. These are all merged to the template automatically if they exist.

They can be found with MSG_[LEVEL]. Additional styles have also been added.

All modules have been updated to use this new/better method.

$.run

First time I'm doing something JavaScript-wise with this engine.

This feature is basically an interface to jQuery's .ready and .load methods.

The main reason I've done it this way is for cleanliness.

There's no sense in executing scripts if they're not needed.

Much like require.js, this will load the method required, and execute it when you need it to.

There is two key parts in this design: a library, and the call.

Currently, theres a sec(urity) lib, which contains an object with the spamCheck utility.

On the template, there's one line: $.run('security.spackCheck', 'ready');

security.spamCheck is referenced into the jQuery.ready function.

There's some pretty brutal hacks within the plugin, but there's no other way to have done it as I see it.

Hope developers find this useful.

Spam checking

Nothing new or special here, it's just an "alternative" to the CAPTCHA that used to be on the registration page.

All it does is:

  1. Count username and email
  2. Populates a hidden input box
  3. Validate server-side

 

This depends on the bot not being able to execute JavaScript, but it's a pretty good measure for today's common bots.

 

I'm also attaching a complete change log this time..

Backwards Compatibility: 
Although attempted, there is currently no guarantee of backwards compatibility with original ezRPG versions.

For a complete list of all changes since last release, please see https://github.com/nands/ezrpg/commits/master. 

Version 0.1b (TBA)
   - Fixed a few bugs in administrator panel where hooks aren't correct executed.
   - Added a better system to send messages between scripts, GET_MSG is now obsolete.
   - Modified template to show avatar as a favicon as well.
   - Added anti-bot validation to the registration page.
   - Added a jQuery library to add specific callbacks at runtime.
   - Updated installer to accommodate new default style. 
   - Improved UTF-8 support, set as PHP default and transfer encoding.
   - Added ToS and Privacy pages(templates), improves SEO. 
   - Created modal dialog utility for use in JavaScripts.
   - Added jQuery 1.8.1 include to template, and copied a CDN into local.
   - Added session expiration(validation of same user access) functionality to the engine. 
   - Created a naming convention used for hooks so files are executed in a specific order.
   - Modified config file to use associative array, will be useful when scaled.
   - Added avatar functionality.
   - Created a scripts directory in /static.
   - Implemented a new style for the default template.
   - Changed naming hierarchy for templates, and created hidden directories used by Smarty.
   - Modified ModuleFactory to reveal config variables to modules(except DB).
   - Removed HTML purifier, too much dead weight to drag around.
   - Mixed PHP notices generated by template on registration page.
   - Fixed a few issues with MSG across a few template files. 
   - Improved layout, now uses a overall wrapper for nav and body divs.
   - Improved signature functionality, uses simple algorithm to compute. 
   - Added option to select password hashing algo' on installation.

Version 0.1a (06/2012)
   - Changed image bars to use only CSS
   - Added MySQL Improved adapter
   - Changed the way in which database adapters are initialized
   - Improved email validation in validate library
   - Implemented PBKDF2 hashing algorithm
   - Implemented bcrypt hashing algorithm 
   - Added passwords hashing performance test module
Edited by Spudinski

Share this post


Link to post
Share on other sites

Like this

Modified template to show avatar as a favicon as well

and this

Created a naming convention used for hooks so files are executed in a specific order

this too

Modified config file to use associative array, will be useful when scaled

Good spot on the GET_MSG I shall have to inform booher of the issue so he can resolve this in the original version too.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...