6
\$\begingroup\$

I'm passing the data to PHP server side which will use the information later as this:

    <script> function encrypt() {
        var salt = CryptoJS.lib.WordArray.random(128/8); 
        var key256Bits500Iterations = CryptoJS.PBKDF2("'.$token.'", salt, { keySize: 256/32, iterations: 500 });
        var iv  = CryptoJS.enc.Hex.parse("101112131415161718191a1b1c1d1e1f");
        var encrypted = CryptoJS.AES.encrypt(document.loginForm.password1.value, key256Bits500Iterations, { iv: iv });
        var data_base64 = encrypted.ciphertext.toString(CryptoJS.enc.Base64); 
        var key_base64  = encrypted.key.toString(CryptoJS.enc.Base64);
        var iv_base64   = encrypted.iv.toString(CryptoJS.enc.Base64);  
        var data = {encrypted: data_base64, iv: iv_base64, key: key_base64};
        document.loginForm.encrypted.value = JSON.stringify(data);
        return true;
    } </script>

My question is, since I am passing this through the form as POST, that still can be sniffed with shark-like tools and then decrypted with all information being passed through anyways.

What information should be private and how should I make them private? How could they be private if the IV, data, and the key are being send through the POST that are needed when decrypting the string?

How is the logic here flawed and how should it be used to protect data communication between client and server side computing?

\$\endgroup\$
6
  • 5
    \$\begingroup\$ Why not just use HTTPS? \$\endgroup\$ Commented Nov 2, 2014 at 9:36
  • \$\begingroup\$ Just providing basic security for small CMS. Case may be that HTTPS might not be available. If I could assure that I could use HTTPS every time, I definitely would use it. Thanks. \$\endgroup\$
    – HelpNeeder
    Commented Nov 2, 2014 at 11:41
  • \$\begingroup\$ I'm thinking of using jcryption.org instead. \$\endgroup\$
    – HelpNeeder
    Commented Nov 2, 2014 at 11:42
  • 3
    \$\begingroup\$ Note that without HTTPS, any JavaScript-based encryption is still vulnerable to man-in-the-middle attacks. A rogue wireless access point or ISP could serve a trojaned jcryption.js to the client and defeat the whole thing. \$\endgroup\$ Commented Nov 2, 2014 at 17:36
  • \$\begingroup\$ I wasn't aware, and thank you for pointing this out. But as Tim suggested using asynchronous encryption would be good-enough protection for this simple project when dealing protecting user data without having HTTPS on every page, which is costly. \$\endgroup\$
    – HelpNeeder
    Commented Nov 3, 2014 at 0:16

1 Answer 1

4
\$\begingroup\$

What information should be private?

The key should be private, everything else can be public (the iv, the source, etc).

How is the logic here flawed

You are using a symmetric key algorithm, which means that the same key decrypts and encrypts data, which in turn means that you would have to exchange the key between the parties (which would need to happen over a different channel, for example paper mail).

What you actually need is an asymmetric algorithm, which has a public key for encryption and a private key for decryption.

If you need to encrypt more data than showing here, you can use an asymmetric algorithm to exchange the key of a symmetric algorithm (as asymmetric encryption is unpractically slow). This is how HTTPS works, for example.

how should it be used to protect data communication between client and server side computing?

Use HTTPS. At the time, there really isn't an alternative for this. (well, you could use third party services such as OpenID). You definitely need asymmetric encryption, and you should definitely not write your own.

Misc

  • either always use camelCase or always snake_case, don't mix them without reason.
  • key256Bits500Iterations is quite descriptive, but I think key would be just fine as well, and easier to read (and what if you change it to 600 iterations? Either your name would be wrong, or you would need to change it).
  • encrypt doesn't just encrypt, it also changes the form. I would to this in a different function and just let encrypt do the encrypting.
  • wherever you do the form manipulation, you should also set document.loginForm.password1.value to something else right there.
\$\endgroup\$
1
  • \$\begingroup\$ Thanks for your opinion. I do not have an access to SSL over HTTPS at this moment. I was looking into this and I think I'll use jCryption instead. Thank you for your words. \$\endgroup\$
    – HelpNeeder
    Commented Nov 2, 2014 at 11:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.