patternjavascriptMinor
Encrypting data on client side and passing it to server side
Viewed 0 times
serversidepassingclientencryptinganddata
Problem
I'm passing the data to PHP server side which will use the information later as this:
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?
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;
} 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?
Solution
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
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.
key256Bits500Iterationsis quite descriptive, but I thinkkeywould 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).
encryptdoesn'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.valueto something else right there.
Context
StackExchange Code Review Q#68645, answer score: 4
Revisions (0)
No revisions yet.