Menu

RTCXpression

Close

A JavaScript and PHP Encryption Technique

javascript php I’m sure many people will agree with me when I say SSL is overkill for a lot of websites. Some websites simply need to secure login processes but not the content itself. In some cases, you can get by with a JavaScript and PHP encryption routine even if it’s something that everyone will tell you to avoid.

If it’s an option, using SSL (even with a self-signed SSL certificate) is always a better idea, but the problem is that it’s not always an option.

The main problem with JavaScript and PHP encryption routines is that they don’t scale well. While they can work perfectly on websites with very few users, they won’t work well at all on websites with a lot of users. The encryption keys have to be created in JavaScript, but they can’t be visible in the source code and they can’t be passed to the server. The PHP code has to test possible encryption keys by traversing database records until valid credentials are found.

The technique I’m presenting is something I’ve tested and used on some websites that needed to be secure and where I was the only user involved.

JavaScript and PHP Encryption Routines

The JavaScript and PHP encryption routines have to be completely compatible with each other. Luckily, Movable Type’s JavaScript and PHP AES implementations are completely compatible.

Because leading or trailing white spaces have to be trimmed before being submitted, you need to add a trim function to the end of the JavaScript code. Here’s one I’ve used:

function trim (str) {
  var str = str.replace(/^ss*/, ''), ws = /s/, i = str.length;
  while (ws.test(str.charAt(--i)));
    return str.slice(0, i + 1);
}


Encrypting and Processing a Login Form

I’m not going to give you a form because there are so many ways to build it. Before you can use the routines, you have to link to the JavaScript file in the head of the page so that it’s always loaded and you have to “require” the PHP file during the processing part.

You need four distinct input fields on the login form. The user name and password have to be fields with ID attributes and without name attributes. Those fields have to be duplicated as hidden fields without ID attributes and with name attributes. Here’s an example:

User Name: <input id="un" type="text">
Password: <input id="pw" type="password">
<input name="username" type="hidden">
<input name="password" type="hidden">

The “<form>” line has to reference an “onSubmit” function, which would look something like this:

<script>
function encrypt{
  key=trim(document.getElementById('un').value)+trim(document.getElementById('pw').value);
  login.username.value=Aes.Ctr.encrypt(trim(document.getElementById('un').value),key,256);
  login.password.value=Aes.Ctr.encrypt(trim(document.getElementById('pw').value),key,256);
}
</script>

The encrypted user name and the encrypted password are the only variables sent to the server. A PHP routine must then attempt to decrypt them using stored user names and passwords until it succeeds.

You also need to include a “token” in the input form and set a matching session variable to be compared during form processing for two reasons: 1) to make sure it’s your form being used and 2) to prevent the encrypted variables from being replayed (this is AES in counter mode, so the encryption results are always going to be different).

Setting a session token is easy. The PHP time function never repeats and can be combined with something else to make a completely different token every time it’s invoked.

Use SSL when Possible

With PHP and JavaScript encryption routines, sessions can still be hijacked by people using packet sniffers. You can shorten their windows of opportunity by regenerating session IDs often but you can’t stop them completely. The only way to be sure an attacker can’t do anything is by requiring login credentials with every form. It may sound like a lot of extra work, but it really isn’t and it especially isn’t when using form-filling password managers.

SSL scales very well and it’s proven technology. With SSL, you don’t have to worry about custom encryption routines. You don’t have to regenerate session IDs and you don’t have to check encryption keys. When used properly, everything is encapsulated and encrypted, including session cookies.

Does SSL slow everything down? Yes, but not enough to be noticeable if it’s set up properly. Fancy JavaScript effects and AJAX routines are way more noticeable.

By:
August 3, 2013

Categories:
Technology

Previous and Next Articles:

« »

You May Also Like:

Comments:

Your comment will appear below the form when it's approved. When the page redisplays after hitting the send button (it can take a few seconds), your comment has been sent.

When replying to someone else's comment, please start the comment with "@" and the name so I can put it in the right place.

Books by William James Asberry
Comments Policy
Privacy Policy

RTCXpression established Feb 28, 2011
Copyright © 2013-2017 RT Cunningham