Safest way to send username + password? [AJAX]

(This question is very php oriented, but relevant)

Hi, so me and my friends are making a game and I've started on the register + login process. I have managed to get it working and passwords are encrypted.

I've looked around the net and have realised that &_GET is very unsafe. $_GET being the use of the AJAX plugin(login.php?username=theziggypops&password=mypass)

Has anyone got any other safer ideas?

(I've heard of using session keys? Will look into it)

Thanks,

theziggypops

You should never send passwords in plain-text!

If possible I would advise avoiding this problem completely - don't use passwords in HTML5 games or apps. It's extremely difficult to make it secure. If you want to check the user is logged in to your site, I would recommend using cookies or session state and simply AJAX a page that says if you're logged in or not (and the server can tell from your session/cookie). Alternatively the server can add something to the HTML of the page containing the game to indicate the user is logged in, and the game can look for that (possibly by a third party plugin). None of these ways needs you to deal with a password.

Currently.. I get the game to hash the password before it is sent and the php salts it. I will look into your session state idea, that sounds like a much safer idea. I will be buying a ssl certificate too.

Thanks!

im quite interested in this, isnt sending the login with ajax like the same as just login from the webpage, its how you deal with the password in the external file is it?

usually in a webpage, it would use a method called '$_POST' and its not actually in the url. as construct 2 can only request pages. you can request a page (using $_GET) with login.php?username=username&password=asdaskdjn or whatever. but also, you should hash passwords at where it is held (usually in a mysql database).

Thats what I think anyway, I'm no expert, it's merely what i've understood from the last couple of days.

yeah i have also looked into it and it seems that 'post' and 'get' are compareble in security, as post is maybe slightly more secure, its how you deal with the input in your php programming, there are many writings on preventing sql injection and better password protection, hashing + salt + random combinations and such, that sayd im also no expert, and still learning all this, must aslo look into this session key

Hi,

If I had to use some kind of authentication I'd:

1) split the authentication process and the game itself

2) use google/facebook or (something else you'd like) to authenticate users

So when user enters the page you can ask him to log in using his existing account on other website. If he agrees to authorize your page and you can display the game. Then if you need to get the ID of the user or some other data connected to the account you can safely ask some php script by ajax and it doesn't matter if it's get or post. Because of the fact that php is authorized you don't need to pass any sensitive data to the script.

here you have some links

authentication using oauth with google account:

code.google.com/intl/pl-PL/apis/accounts/docs/OAuth2.html

and authentication using facebook:

developers.facebook.com/docs/guides/web

facebook makes it easier to implement it but I'd suggest to use either oauth or both

I hope you get the idea. If something is not clear I'll try to answer any questions as good as I can. :)

IMO hashing the password before sending it still is insecure, you are still holding the password in the javascript code in the browser when you don't need to. If the user presses Ctrl+Shift+J and hunts around in Chrome's debugger they can probably find the unencrypted password. Maybe no big deal if it's your password, but then it's vulnerable to javascript injection or XSS attacks that can let an attacker get the unencrypted password!

I don't see any reason at all to deal with passwords in a HTML5 app, it's always going to be insecure, and there's no reason to - you can do it all securely with the traditional cookies/session state. I strongly recommend you change your login system to never use passwords in the Construct 2 itself.

Hi,

I don't have much expertise on security but what I do agree that sending the password in clear text over the wire is too risky and not recommended. And if you even hash it, it does not shield you from hackers attacks since they don't even need the real password if they know the MD5 hash value that's being sent by sniffing the connection packets or airwaves and finding the hash.

This also does not include the risk of session hijacking when one does not have SSL which protects against eves dropping, amongst other things.

Interesting reading you can read to get more exposure on security.

owasp.org/images/0/0f/OWASP_T10_-_2010_rc1.pdf

There is some article which helps to deal with situation when you use JS and you don't have https. It requires hashing coupled with challenge key both on client and server. It helps to minimize the risks but not completely though.

switchonthecode.com/tutorials/secure-authentication-without-ssl-using-javascript

While it is widely used, it is not safe.

marakana.com/blog/examples/php-implementing-secure-login-with-php-javascript-and-sessions-without-ssl.html

I'm currently working of something which deals with security as the topic of this thread. Briefly, it deals with handling password through image recognition similarly done with some site to prevent bot but with a twist.

Let me explain. Instead of entering password, user will be asked to click his password through randomly assigned position that visually he knows where to click to match his password. Bot can't do that and if the buffer happened to be defeated and sniffed, it can't be really used because of time token and session id associated with it will invalidate it. And more, the next time, this password is resent, it will be either expired or incorrect since it is going be changed again preventing from guessing it right each time. The reason for this is the challenge image is not the same for each time the login is invoked. Then, only and only the server knows and how to decrypt it to decode it and perform custom authentication to database. That's the idea.

Hopefully, I can soon integrate that feature to the current game in progress!

Cheers!

SF

We currently hash the password and username together as a single unit before shipment on login, but this still requires the user's browser not to be compromised (which you can never be sure of). We are probably going to add a dynamically variant salt that the server will ship to the user's browser with a one time salt to hash with that will expire on a successful login.

Once the user is logged in everything is tracked via a session id which ties into a server-side cache containing all session details.

We will eventually go SSL, but for now we are in development.

Ashley

How to make a log in, without make a log in? I'm confused about your description..

You said..

"If you want to check the user is logged in to your site, I would recommend using cookies or session state and simply AJAX a page that says if you're logged in or not (and the server can tell from your session/cookie)."

Cookies, session from where? And how can it be applied on Crosswalk methods..

You have any documentation or explanation to share about that?

PS: I am following the issue: https://code.google.com/p/play-games-pl ... il?id=108.. its a good implementation..

For Crosswalk.. a integration with Google Play would be quite enough to start.

Well you bumped a thread where I made comments about three years ago, and my stance has changed: as long as you have a decent SSL implementation, you should be OK - but you should still send password hashes and not actual passwords, so they're not even plaintext on the receiving endpoint. Anyways I don't consider myself a security expert so don't ask me.

There is no safe way. There is always someone there to hack it.

This is what SSL is for, it will encrypt the details over the network.

johnwalker if you say so but, me I don't trust anything. If there is will there is way. I am sure there are someone whom is better at hacking. Nothing is safe