Contradicting info about user authorization?

Hi,

I read one thread where someone created an auth system in PHP that wrapped around the game, and wondered how to pass the session cookie into the game. The response to that thread was that it'd be better to send the request from within the game so that the cookie could be fetched via AJAX.

Then I read another thread suggesting that authing from within C2 is insecure, and that allowing the user to input their password into C2 is next to impossible to make secure.

I'm building an online feature for my game that requires authorization, so I'd like to know how I'm supposed to do this if I can't do one or the other?

Thanks in advance.

Bump.

Any JS wizards around? :)

Sorry for bumping but I think this is a somewhat important point to address. As far as I know there hasn't been a proper discussion about this yet? Or perhaps I'm wrong?

Just don't store any personal/sensitive/payment information and it should be fine even if it gets hacked?

Players wouldn't lose anything other than restorable game-related stuff, right?

Yeah but from the perspective of games being what we're developing here, it's pretty important that they're as secure as can be. There's no reason to cut corners unless you want to for whatever reason.

Also, issues like these are especially important if you're making persistent state online games like MMOs. :-)

I'm imagining good security in Construct 2 is very difficult to achieve with regards to that you have very little direct control over most of the information flow.

I think the issue is quite negligible - If you're making a persistent state online game like an MMO then you're looking at the wrong game engine.

It's not a question of whether it is or isn't possible. It's a matter of looking at the potential solutions, analyzing them and picking out the best way forward in terms of security.

As of now I've seen topics suggesting to pass an auth variable into your game from outside, and others to auth from within the game using AJAX. I have also seen posts rejecting both ideas in favor of the other, so I'd be interesting in seeing what Ashley thinks, as well as other users. :-)

Don't store or hard-code any passwords, and use secure servers. If the user enters a password in to a text box, then you make an AJAX request to a secure server (URL starts with https://) to verify the login, and you don't store the password they entered on the client side, that's about as secure as an adequately written web page form.

Thanks for that clarification.

You said something in another thread about not using passwords at all since it'd be available in the user's dev console at any time, or something to that extent. What about that?

The way I do it now is I have a single index.php which is used for logging in, authing against a MySQL DB, returning a session string, loading the game (via echo from wihtin the PHP file) and passing that session string into the game by setting it as a cookie with PHP, and then loading it up in-game by using the Cookie plugin.

What is your take on such a solution? Better or worse than what you just suggested?

Bumping this so we can have a proper conclusion in one single thread.

Bump.

Bump.

Hi, did you complete or make any progress with your solution talked about in this topic?

Yeah I'm still working on it, but if you need help you can hit me up on IRC.