Encryption/Decryption between PHP and Javascript

Question

I am looking to expand beyond this question: Obfuscating POST variables between Javascript & PHP

Where I came up with this solution : http://pastebin.com/YuAAZTLi

It work's 95% of the time but the 5% I can't really deal with. It's hard to really base it on the time of two different servers. And sending the rot with the variables is just too easy to crack.

I need something that changed each and every time hopefully, because I dont want the HTTP POST requests just to be duplicated. What encyrption methods exist interchangeably between javascript and PHP that allow for md5 type encryption. Where

4500 looks something like Dusfh7sfSFJf78dfns8 and 4501 something like JF7Fhene7fdHfdshf6d ..nothing alike even though they are 1 digit off.

External Librarys are permitted but please make sure you link both a php and javascript counterpart.

• Kerrek SB: MD5 is a hash algorithm, not an encryption. You can't undo hashing on the server side. You can only look up hashed values in a dictionary, but then so can the attacker.
• Brad: Why not simply use HTTPS? The client will always be able to easily decode your data anyway, so you should only really concern yourself with transit.

Answer 1

It's somewhat specific to the case of handling user login, but I proposed a protocol in this answer, and the asker ran with it and coded up an HTTP-sniffer-resistant PHP-to-JavaScript login form implementation.

The essentials of the scheme:

• Generate a random nonce value; this helps prevent replay attacks.
• Send that nonce value and the password salt to the browser along with the rest of the login form.
  • You are storing passwords in salted and hashed form, right?
• When the user enters a password, have the script on the form compute and send back hash(hash(password, salt), nonce) instead.
• When the server receives the form submission, have it compute hash(storedSaltedPassword, nonce) and verify that it equals the submitted value.
  • Retain the nonce value at the server; don't trust the client to echo it back to you, or your replay protection is gone.

The weakness of this scheme is that the password hashes in the database are in some sense password-equivalent; while it's likely infeasible to extract the original password used to produce those hashes, knowledge of the stored hash is sufficient to impersonate the user on your site.

Answer 2

Just use SSL. It's commonly supported by pretty much everything, and the security issues have already been worked out extensively. Setup is a bit tricky, but there's tons of information on how to do it out there; even the certificates aren't that expensive anymore.

• ParoX: SSL is only made to hide the information from third party. The encryption itself can be read with an HTTPS sniffer on the client side. I want to prevent the client themselves from really know what they are sending or what they are getting back. It's more of an obfuscation than an encryption
• Philipp Gayret: @BHare you can never prevent a client from altering the JavaScript itself, this is super easy, you are now relying on the client to not look at the JavaScript.