3 ms·
Be careful: if you are using a javascript library to encrypt data, you get protection from eavesdroppers, but not from man-in-the-middle attacks. If I can alter
by oconnore 15y ago
Be careful: if you are using a javascript library to encrypt data, you get protection from eavesdroppers, but not from man-in-the-middle attacks. If I can alter data that you send/receive over the wire, I can simply modify your aes function calls to xor the data with a predictable sequence that I generate. The only way to prevent this that I have thought of is to store the site (which has presumably already been acquired over a secure channel) locally on the client's machine, and make AJAX calls over the encrypted channel for fresh content.
- thaumaturgy 15y ago> *...if you are using a javascript library to encrypt data, you get protection from eavesdroppers..." Nope. Replay attacks. Piece of cake. The number of things that JavaScript does better than SSL is 0.
- oconnore 15y agoI don't think you know what you are talking about. If your authentication is implicit in the decryption of the messages, replaying that data will accomplish nothing. For example, if I share a secret "password" with my server, I can do this in javascript using any symmetric cipher: ToServer: "My name is oconnore" ToClient: cipher(iv1, "(C1) Hi oconnore. Use this! iv2=rng()"++msghash, "password") ToServer: cipher(iv2, "(C2) Thanks, give me my data please!"++msghash, "password") ToClient: cipher(iv3, "(C3) <Some data>, and iv4=rng()"++msghash, "password") ... If an attacker repeats any of these messages, the client/server will discard them based on the counter. Of course, for real use you would need to use public key crypto to avoid storing passwords in what is essentially plaintext, but I thought this would illustrate how replay attacks are a non issue. Of course, as noted before, all this is irrelevant if you are sending your code over a channel vulnerable to MITM...