Some of the guys here are developing an application which incorporates some 'secure areas' accessible by logging in. In the past, the login form and subsequent 'secure' pages were all plain text transmitted over http, as it's an application that goes out for use on shared servers where there is little chance of being able to use SSL (think WordPress and the like). Most people just shrugged their shoulders as that's all they expected - it's hardly a national bank.
We are now thinking of writing the next version using a JavaScript front end, with the advantage of loading all the images & CSS once, then writing HTML into the DOM thereafter with extJS (or maybe jQuery). We'd like to encrypt user input at the client before being sent to the server, then decrypt server output at the browser before being rendered to HTML so as to introduce some sort of security for users. There are also gains to be had with reducing page loading times, as we're only sending gzipped JSON back and forth.
While playing around, we realised that the method we were looking at to encrypt the basic stuff also doubled up as an authentication mechanism for login in the first place.
For simplicity...:
- The user connects to the login page over standard http, where the browser downloads the JavaScript package containing the hashing and encryption algorithms (SHA-256 and AES for example).
- User enters
username,passwordandsecretinto a login form. - The browser JavaScript sends a hash of
usernameandpasswordto the server via AJAX. Thesecretis only stored in JavaScript and is never sent across the internet. - The server looks up the hash and retrieves
usernameandsecretfrom the database. - The server sends a hash (same algorithm as the browser) of
usernameandsecretback to the browser. - The browser JavaScript creates a hash of
usernameandsecretand compares it to the hash sent back from the server. - If they are the same, the browser JavaScript encrypts
responsewithsecretand sends the message back to the server. - The server decrypts the message with
secretto find the expectedresponseand starts a new session. - Subsequent communications are encrypted and decrypted both ways with
secret.
There seem to be a few advantages of this type of system, but are we right in thinking:
- The user knows they are talking to their server if the server manages to create a hash of
usernameandsecret, proving the server knows and understandsusernameandsecret. - The server knows the user is genuine if they manage to encrypt
responsewithsecret, proving the user knowssecret. - At no time is
secretever transmitted in plain text, or is it possible to determinesecretfrom the hash. - A sniffer will only ever find out the 'secure' URL and detect compressed hashes and encryptions in the query string. If they send a request to to the URL that is malformed, no response is given. If they somehow manage to guess an appropriate request, they still have to be able to decrypt it.
It all seems quick enough as to be imperceptible to the user. Can anyone see through this, as we all just assumed we shouldn't be playing with JavaScript encryption!
Don't do this. Please use SSL/TLS. See Javascript Cryptography Considered Harmful.
If you can provide a single SSL site to deliver your JavaScript securely (to avoid the attack mentioned above), then you can use the opensource Forge library to provide cross-domain TLS connections to your other sites after generating self-signed certificates for them. The Forge library also provides other basic crypto stuff if you opt to go in a different direction. Forge has an XMLHttpRequest wrapper that is nearly all JavaScript, with a small piece that leverages Flash's socket API to enable cross-domain communication.
来源：https://stackoverflow.com/questions/7432556/javascript-asymmetric-encryption-and-authentication