Question

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, password and secret into a login form.
• The browser JavaScript sends a hash of username and password to the server via AJAX. The secret is only stored in JavaScript and is never sent across the internet.
• The server looks up the hash and retrieves username and secret from the database.
• The server sends a hash (same algorithm as the browser) of username and secret back to the browser.
• The browser JavaScript creates a hash of username and secret and compares it to the hash sent back from the server.
• If they are the same, the browser JavaScript encrypts response with secret and sends the message back to the server.
• The server decrypts the message with secret to find the expected response and 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 username and secret, proving the server knows and understands username and secret.
• The server knows the user is genuine if they manage to encrypt response with secret, proving the user knows secret.
• At no time is secret ever transmitted in plain text, or is it possible to determine secret from 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!

Answer 1

Don’t do this. Please use SSL/TLS. See Javascript Cryptography Considered Harmful.