Pass username/password to another javascript file safely

Question

I am running Socket.IO and have the server part confirming username and password via a mysql query (run in js), which works great. My question is: Is it possible to send the clients username/password from the clients javascript to the servers javascript file safely? Without a user being able to see the password? The password is already hashed (via PHP) but I don't want them to have there hash to be able to possibly decrypt.

// Edit

After further discussion I agree it is bad to send a hashed password anywhere besides the script it resides on. Is there another way to uniquely identify a user and pass those variables via javascript so my server js file can authenticate them (without a password)?

Answer 1

One typical way that user authentication is done is that the user supplies the username/pwd via SSL. That is compared to the credentials on the server (often via some hash algorithm as you have described). If the credentials verify, then the server creates a session ID for that user. The session ID is temporarily stored on the server somewhere and it is returned back to the client in a cookie. All subsequent web requests will verify that a session ID that is valid for this user is in the cookie. If so, then it's still the right user.

The session ID has nothing to do with the user's actual credentials and should be different every time the user logs in so there is no long term risk to the user's credentials with a session ID. Instead, the session ID is just a temporary token that was issued to a browser that correctly supplied user credentials so the server can know (on subsequent page requests) that these requests are coming from a "logged in" user.

If the session ID is stolen (via man-in-the-middle snooping or something similar), then anyone with the session ID can temporarily access the account. So ... if you think the session ID needs to be protected, then you need to require SSL for both the initial authentication and all subsequent page access that uses the session ID.

Session IDs can be temporal (expire after some period of time) and the server can revoke one at any time by simply refusing to accept it any more as an indication of an authenticated session. In this regard, it's a lot simpler/safer than using any real and long lasting credential as your repeated indicator of a secure login.