Leon's Weblog

October 28, 2009

PHP Authentication Over Unsecured Internet Connection

Filed under: Software Dev — Leon @ 7:50 pm

When I wrote my earlier article on Managing Users in a PHP Web Application, I neglected to mention that the authentication mechanism is only acceptable when users are connected over a secure connected (HTTPS) or are on a trusted network (such as a corporate intranet). We went through great lengths ensuring that the passwords are stored securely in the database and that the site is not susceptible to SQL injection or XSS techniques. However, when the login form is submitted over an unsecured internet connection the password is sent back to the server in plain text. Anyone lurking on the network can easily get the login credentials using a network sniffer such as Wireshark. The solution to this problem is to hash the password using MD5 on the client side prior to submitting the login page. This is similar to how we hashed the password stored in the database to prevent people with access to the table from viewing users’ passwords.

The following article goes over the technique of securing client-side passwords using a JavaScript implementation of MD5. The key to take away from the article (besides the JavaScript code for MD5) is that the user’s password is hashed and submitted in hashed form only. In my case, I simply replace the clear text password with the hashed version prior to submitting the login form. This is the only change required to the login form code implemented in the previous article.

<input onclick="document.form.txtPW.value=MD5(document.form.txtPW.value)" name="Login" type="submit" value="Login" />

Note that this solution will only work if the client has JavaScript enabled on their browser. You can use FireBug’s network panel to verify that the clear-text password is not transmitted.


  1. This is not a secure solution since anybody, who would be able to catch plain text password, will catch the hash. And authenticate himself by sending it directly to server (by using firebug to modify form or by simply writing his own form).

    Did I miss something?

    Comment by kebet — December 11, 2009 @ 4:50 am
  2. You are absolutely right, kebet. This does not prevent replay attacks as you described. To fix this, the client would have to send back a hashed value of the clear text password appended to their unique session id. This complicated things a bit because we don’t want to store clear text passwords in the database either. I prefer storing a hash of the user’s clear text password appended to their user name to prevent dictionary attacks on the users table. So to authenticate, the client would have to calculate the following:

    MD5( MD5(clear_pw + name) + session_id )

    Of course forcing connections to use HTTPS is a lot easier.

    Comment by leon — December 11, 2009 @ 1:30 pm

RSS feed for comments on this post. TrackBack URI

Leave a comment