I know that this question has been asked many times, but would JavaScript encryption work if I just added 100 random numbers and letters to the password? That would be hard to reverse engineer, because it's totally random. I am making a WordPress and Joomla kind of service, and all the user's that download it do not have SSL.

  • 2
    How will you know that your "random" numbers and letters are really random? Javascript's Math.random() function only generates pseudo-random numbers, and their randomness (or lack of it) is implementation-specific and cannot be trusted. – Mike Scott Jul 26 '15 at 7:27
  • Are you trying to securely store passwords for a web service login? – Neil Smithline Jul 26 '15 at 19:39

No, you seem to have a misunderstanding of how encryption and obfuscation work. Encryption provides confidentiality: a message is hidden with a mechanism using a shared secret from all parties not possessing that secret.

Obfuscation refers to a number of techniques employed to make, in general, a scripting programming language application difficult to understand to a human reader. They take as input the application in its original (human readable) form, (a key) and output a functionally equivalent application, larger in code size and far more difficult to understand.

Now to answer your question, no it will not work as you mention there may be no authentication nor encryption, meaning that any passive attacker(using a packet sniffer and located in the same network as one of your potential visitors(i.e. victims) simply retrieves the password/javascript code in plaintext.

| improve this answer | |

What you describe sounds like obfuscation, not encryption.

Please do not use "invented" encryption or hashing algorithms (please read this OWASP write-up).

If you'd like to use password-driven keys, check out this JavaScript library for key derivation.

There are several JavaScript libraries that implement AES (check out this StackOverflow post) and other encryption ciphers. Key management would be tough, but you can give it a go.

| improve this answer | |

Another problem not mentioned yet: you mentioned the JavaScript is served over plain HTTP. This means that a "man in the middle" (MITM) attack can modify the JavaScript enroute, removing the encryption, or even doing more nefarious things. You CAN do encryption client-side (there are some cases this makes sense) but it CANNOT replace HTTPS, only supplement it.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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