Building a CHAP Login System: Encrypting Data in the Client
(Page 1 of 4 )
Web developers concerned with the security of their applications face one of their worst fears every time someone logs in: the possibility that passwords will be passed in plain text. Fortunately, there is a way to avoid this security risk. In this article, the first of three parts, Alejandro Gervasio helps you tackle this problem with a Challenge Handshake Authentication Protocol login system.
Introduction
For most web developers, creating login forms to interact with web programs can be a sometimes frustrating experience. And each time I sit down to code some forms, I’m assailed by a feel of distrust that affirms my deepest fears, particularly when I think that passwords will be passed in plain text whenever users try to log in to the application. Certainly, this feeling might be considerably mitigated if I get into the implementation of straightforward solutions such as https, but unfortunately for many websites, this is still a long way from being an acceptable option.
Even if I were to code the login system while bearing in mind some kind of persistent mechanism like session cookies, to avoid subsequently transmitting login data from page to page, passwords would still be passed in unencrypted form to the server -- at least for the first time users attempt to log in. However, despite the complexities inherent to transmiting sensitive data across an insecure network, there is a fairly straightforward method for tackling the problem.
Of course when I say “a straightforward method,” I’m introducing the concept of client-side data encryption, most of the time performed through the implementation of the cryptographic MD5 hashing algorithm in JavaScript. Through this method it’s possible to build a CHAP (short for Challenge Handshake Authentication Protocol) login system, which allows the client to send the MD5 hashed value of the password and a challenge string combined, to be authenticated on the server. This in turn builds the same string on its side, calculates the MD5 hash and compares the result with the value received from the client. If both values match, then the client is authenticated.
Certainly, the clearest advantage of this method rests on the fact that the password is never sent as clear text from the client to the server, thus the possibilities of being sniffed out by a hacker are significantly reduced. Now that you have a pretty clear idea of how sensitive data, and particularly passwords along with challenge values, can be encrypted in the client, it’s time to go further into the real implementation of a CHAP login system.
Over the next few pages, I’ll be explaining some core concepts to be evaluated when working with client-side data encryption, in conjunction with several examples of CHAP login systems that can be used in real web applications. My trusty workhorse in this journey will be the excellent MD5 JavaScript library released by Paul Johnston, which I’ll use throughout the examples implemented across this article series.
With the preliminaries out of our way, let’s get started.
Next: The basics of a CHAP login system: pros and cons of client-side data encryption >>
More JavaScript Articles
More By Alejandro Gervasio
