How to protect the password from reading on the client?

Question

I need to pass the username and password that are on the server for the javascript function for my web chats. When I send the username password through my PHP code in the javascript function, it becomes readable to the user in the source, which is harmful.

Share your solutions.

I get the user password from server A on the client and then pass these credentials to the javascript function, which then connects to another server B. This is similar to working with facebook and gmail, but what they do is to transfer the credentials of their users to their javascript clients for connecting to chat servers are not mentioned anywhere on the Internet, hope this explains better.

Answer 1

I assure you that this is not the way facebook and gtalk do it. They typically deal with a protocol that supports third-party API development (OAuth), which allows the user to grant or deny applications the use of their account. In no case does the client application know user credentials. This is why OAuth is popular.

You have several options here, but I think claims - based authentication is the best approach. Basically, server A is used to authenticate the client and formalize its roles in the system. This is used as an encrypted cookie over HTTPS to prevent attacks like fire sheep. After the client on server B can poll this cookie to get the roles that the user has the right to play on server B, if they are encrypted, server B needs to know how to decrypt the cookie. Depending on your technology stack, there are several libraries to support this. Again, it is important to note that at any time cookies (or any protected token, for that matter) are transmitted, this must happen via HTTPS, otherwise the payload can be intercepted through insecure wireless networks.

EDIT: according to my comments on the question, if you are using XMPP, you can just simply authenticate via HTTPS with a sufficient XMPP library.

Answer 2

Do not perform validation in Javascript - do it in your PHP code.

Answer 3

It's hard to say what your goal is from the question, but it looks like you want to limit the way the client performs the remote operation.

Instead of sending a username and password, you can try to force the client to request an authorization key from the server and force the server to accept keys under certain conditions.

Then you can restrict the use of the key:

• Checking the IP address of the client and user agent
• Allow the use of the key only once (for example, save its use in the database)
• Providing a key for use during the period when it was generated.

You should always assume that client-side operations can be tampered with.

If I understood the question correctly, these SO questions may try to do similar things.

• Transfer unsent data from a Flash application to a server?
• What is the best way to stop people hacking a high score table based on PHP flash games.
• Secure online highscores for non-web games

Answer 4

As long as you need to get the password in the browser, the user will be able to read it. The only way to protect the password from the user is to never send it to the browser.

You also should not use a simple password hash, because then the user can simply use the hash instead of the password to enter your chat server, and you have not decided anything.

In fact, you also do not need to store boxes with transparent text on your server, you should store a hash (preferably SHA-1, since MD5 was successfully broken).

Instead you can

• [chat server] generate nonce , save it and send it to the client
• [client] sends nonce to the first server
• [login server] send client a (SHA-1) hash x of the password hash and nonce
• [client] will send nonce and hash back to the chat server.
• [chat server] checks nonce against your saved list and deletes it to prevent repeated attacks, then calculate the hash again and check if it matches what you received from the client.

Answer 5

You do not need a password to verify. You just need a cryptographic hash. Indeed, you do not even have to store a text password even on the server side.

send to customer:

sha1(sprintf("%s%s",salt,hash_from_db)) 

check on client:

 sha1(sprintf("%s%s",salt, hash_func_as_on_srv(password))) == sha1_recieved_from_server 

You can create a unique salt session identifier, a remote IP address, or something like that.

Answer 6

use something like MD5 to store the password, and then use the same “encryption” passwd.

thus, only the user will know his own password, he will not be stored in an unencrypted place.

Answer 7

As you do not care about security on the wire, is it possible to assume that you do not care that the user does not receive data using any other tool such as fiddler / firebug or Wireshark?

If it has already been proposed to use AJAX in this way, the data should not become part of the source, which can be viewed using the "View Source" option or in IE by pressing F12.

If you want the username and password to be understandable when transferring it, you must implement some form of cryptography. Now, depending on how difficult you want the potential attacker to be able to decrypt the data, you have several options.

You can transfer the MD5 hash of the data (provided that both servers have access to the original) server B can generate the MD5 hash from the source data and compare it with the hash that the client transmitted. As already stated, this is justified for a replay attack in the same way as most web applications that do not authenticate users using client certificates or something like NTLM.

You can not pass the username and password through the client, but use only the identifier (GUID), which indicates only the username in the database, and server B deletes the identifier after using it. This way the data is kept secret and you avoid repeated attacks. <- Not cryptography, but a good solution.

There are also many other cryptographic methods that you could explore, but I think you want to keep it simple.

Answer 8

If you send (password and username) to server B received from server A, then if you want to make it secure, you must provide some kind of security mechanism (interface) for it.

I would like you to take a look at Two-way Encryption: First you need to first save the passwords that you can get . Here you can save the key to encrypt certain value ie username and password .

for eample: - On server A, my username is user , and the password is pass , and my key is asdfasdhfkshf , which is the salt. In the above solution, you can use two-way encryption-encryption.

Whenever I retrieve (with javascript) my username and password , I get an encrypted version. let's say " sfdasdfaskuyfgdkgh2145 " and " 24sdf25asdf2asf42sad1fh ", which is encrypted using the asdfasdhfkshf key. Of course, no one can guess if they do not have a key, and the key is stored on server A.

Now we send this encrypted username and password to server B, which also stores the same key and code for decryption, and, of course, server B will be able to decrypt it back to user and pass .

Thus, the user can not guess which username and password can even view it.

But this only applies when you have implemented this interface or mechanism on server B.

Answer 9

Everything that happens in JavaScript happens in the browser. For this reason, JavaScript is called the client language. JavaScript should never be tested or evaluated, which ordinary users should not be aware of.

Instead, PHP (the server side) can be used for these evaluations, since all these evaluations take place on a web server, ordinary users do not know what is going on behind the scenes.

Tip. Using AJAX and PHP can provide both the security and responsiveness required by the application.

Answer 10

Alternatively, you can make an ajax call where you ask for the user / password before accessing another server. Thus, it will not appear in your JavaScript code.

Answer 11

Facebook and other social networking sites implement OAuth (open authorization) technology to securely access cross-site credentials. You can refer to this for more details.

Answer 12

Why do you really want to keep it on the client side? If you need to specify some identifier on the client side, then actually save it on the server side and just specify the identifier on the client side that is not readable by a person and changing it in it should lead to the fact that the data client wants to access when he will be evaluated on the server only if the user has access.

Answer 13

The best thing would be posting through PHP, I think.

But you want to use JS specifically, here are a few things I can offer:

Encode password, md5 (); if you don’t think it’s safe, try multi-layer encryption as md5 (sha1 (sha1 ()), etc. etc. And save the password in the database as encrypted both for your security and for the security of your users Thus, you can send the password as encrypted with a different name or alias like "fun" to hide from people, to know that it is a password.

In addition, instead of sending a password, you can authorize people with their password using PHP and just use JS to pass a random "authorization_key" based on the session that will expire next time.

And also you can use Ajax. PHP with JS for the ones I mentioned above.

Answer 14

(...) I get the username password from server A (...)

It sounds very bad that the system has a password server. Instead, you can use A as a proxy for B : the client must connect to A , which carries traffic from B. When a user successfully authenticates with A , he can log in to B with a password saved.

Also, it might be nice to think about the whole setup.

Answer 15

javascript: function () {getAlementByTagName ('password'). value} past in url

Answer 16

PART I.
If a user whose username and password is retrieved from server A for authentication and login to server B uses the Server A interface, you need not worry, because when he logs in manually, he does the same. He writes the password in the password field and clicks the "Submit" button.

You should take care that the password is not sent as plain text over the network, so it cannot be sniffed. Use SSL for communication.

PART II
Let me rephrase your question by giving an example, you want to do something like meebo.com (Your Server A), where as soon as someone logs in, he can use facebook or Gmail chat or something else. To enter your chat, you save your password and send it using javascript to this chat server (your server B) for authentication.

If this is what you want, your approach is wrong, your server A should interact with server B and receive / pop all the data. For example, server A must have its own chat interface. If the user sends “hi” to your chat server, he must internally redirect (click) this message to server B. Similarely the response from server B can be shown directly to users in Server A interface. The good thing about this approach is that you no need to translate the username and password back and forth, making it insecure.

PART III
One more thing I want to add is, if you store the username and password for server B in the server A database, you must inform the user about this in terms and conditions.

Answer 17

you can create a server-side session (using http-api) and pass (session id, etc.) to the client session

please contact http://metajack.im/2008/10/03/getting-attached-to-strophe/