User Password protection

Readers are often asked how to use JavaScript on their site to ensure that passwords are not leaked when a user logs on. My first response to such a problem is to tell them to use SSL (Secure Sockets Layer). If used correctly, SSL is the best solution for Web applications with high security requirements. However, there are also a significant number of developers whose Web applications require little security, so they do not want visitors to log on with SSL.

Web applications typically use a technique called session state Management to track and manage interactions between browsers and servers. Because each browser's browsing requirements are independent of other browsers (as defined in the Hypertext Transfer Protocol), Web applications must use certain techniques, such as cookies, hidden table fields, or rewrite URLs, that identify the server's standalone session with a browser. Most server-side programming environments (such as ASP, PHP, ColdFusion, and so on) use cookies.

The problem with session state management is that it is fundamentally unsafe. These cookies, form values, or URLs that are used to manage session state are routed between browsers and servers, and hackers can intercept them on the way. Once the interception succeeds, hackers can use the information to forcibly take over the user's session.

In most server-side scripting environments, you can take steps to reduce the incidence of such leaks. For example, you can set a short lifespan for cookies and apply the "difficult to expect session state" message. However, the safest solution is to use SSL. With SSL, both the user's password and the session-state information are protected.

If you do not use SSL, you can ask the user to authenticate each sensitive page in your application. However, from the user's point of view, this approach is too much trouble. In short, you need to be aware of how risky you and your users are willing to take. If the risk of a password leak is too high, you need to use SSL to establish an application. If you cannot use SSL, you can replace it with a MD5 based login. It can at least protect your user's password from leaking out. In addition, a server-side scripting technique that prevents session-state information from being stolen is selected.

Typically, if a user does not use SSL to log on (that is, the original HTTP), the user password is unprotected from the time it is left to the destination network server, as shown in the chart on the next page.

However, we can use an irreversible function to develop a login scheme that does not expose the user's password. A function is a correspondence between the elements of a collection, and in a function from set A to set B, each element in a has a unique element in B that corresponds to it. Irreversible functions are difficult to reverse in computation-that is, given an element in set B, it is difficult to determine which element in the set a corresponds to it.

It's like a paper shredder. It is easy to put the paper in the Shredder. But on the contrary, it would be even harder to put the pieces of scraps of paper back together as the original.

　　 Adopt MD5 Solution

One of the most popular irreversible function applications today is the MD5 algorithm developed by Ronald Rivest. Ronald Rivest is also one of the leading developers of RSA (Rivest,shamir,adelman) encryption algorithms. The MD5 algorithm generates a 16-byte "digital fingerprint" for any length of information. This information can be a string, a file, a text stream, or any other form of byte sequence. In RFC1321, there is a detailed description of the MD5 algorithm.

We want to develop a login method that uses the MD5 algorithm to protect user passwords sent from one browser to a network server.

When a user makes a logon request for a network application, its network server provides the user with a login form. This is a table with a randomly generated value. The random generation value of the server-side script is randomly selected from a hundreds of millions of-note value space.

The user enters his or her username and password in the login form, and the client script appends a random value to the password, and then computes the result using the MD5 irreversible algorithm. Replace the original password with the calculated value. I call this value the MD5 password.

Finally, the client script sends the username and the MD5 password to the network server. Because the result of the MD5 operation is transferred between the browser and the server, no one can calculate the original password entered by the user.

The network server performs the same operation as the user's browser after receiving the username and MD5 password. It appends a random value (that is, a random value that has been sent to the user) to the user's password (extracted from the protected area of the server) and calculates the correct MD5 password value. The network application then compares this value to the value it collects from the browser. If the two values are equal, the network application generates a server-side session variable that proves that the user is correctly identified.

Speaking of which, you may question the necessity of using random values. In fact, this random value is used to prevent the recurrence of attacks. If only the original user password passes through MD5, the corresponding MD5 password will always be the same value. Hackers can also log into network applications as long as they intercept MD5 passwords. When random values are used, the MD5 passwords generated at each logon are unique, which prevents the above problems from appearing.

　　JavaScript implementation

It is easy to implement a login scheme that uses MD5 encryption in JavaScript. Paul Johnston's site provides you with a wealth of information about the implementation of the MD5 algorithm. Other information about MD5 can be found in this site. Please copy the code to a text file and name it md5-js.txt.

We will complete the server-side scripting in the ASP environment (because the ASP supports jscript--Microsoft version of JavaScript). You can use any kind of server-side scripting language, but you must translate the MD5 algorithm into the language you choose.

The following is a login form Login.asp implemented in an ASP environment. You can simulate an online login to simulate the user named Jason, user password for f2#5%rsq.

<%@ LANGUAGE = "JScript"%>
<HTML>
<HEAD>
<title>please Log in!</title>
<% session ("sharedvalue") = Math.random (). toString ()%>
<script language= "JavaScript" src= "Md5.js" ></SCRIPT>
<script language= "JavaScript" >
var sharedvalue = "<% =session (" Sharedvalue ")%>"
function Handlelogin () {
Sendmd5value (Calculatemd5value ())
}
function Calculatemd5value () {
var pw = document.forms["Login"].elements["password"].value
PW + + Sharedvalue
return calcMD5 (PW)
}
function Sendmd5value (hash) {
document.forms["Login"].elements["password"].value = Hash
document.forms["Login"].submit ()
}
</SCRIPT>
</HEAD>
<BODY>
<form name= "Login" method= "POST" action= "checkpassword.asp" >
User ID: <input type= "TEXT" name= "userid" size= "><BR>"
Password: <input type= "Password" name= "Password" size= "><BR>"
<input type= "button" Name= "Startlogin" value= "Login" >
</FORM>
</BODY>
</HTML>

Only three lines of the above content contain ASP scripts. (The content between <% and%> is ASP script.) The first line of the file identifies the ASP language as JScript.

<%@ LANGUAGE = "JScript"%>

In the second line of ASP, the value of the server-side session variable named "Sharedvalue" is set to the string representation of the random floating-point number "string". This session variable is present in the server throughout the user session.

<% session ("sharedvalue") = Math.random (). toString ()%>

The following line sets the client-side JavaScript variable named "Sharedvalue" to the value of a server-side variable with the same name.

var sharedvalue = "<% =session (" Sharedvalue ")%>"

The user enters his username and password in the form and clicks on the "Log In" key, which activates the Handlelogin () function. The Handlelogin () function starts the Calculatemd5value () function, appends a random value to the user's password and calculates the corresponding MD5 value. The Sendmd5value () function then collects the value and replaces the user's password in the original form with the final submission of the form.

Here's one thing to note: a single line of script tags indicates that the scripts contain md5.js files. The above is the implementation of MD5, you can (and should) copy this algorithm from Paul Johnston's site. The calcMD5 () function used by the Calculatemd5value () function is defined in detail in md5.js.

On the server side, we use an ASP script named Checkpassword.asp to confirm the username and the MD5 value. The script reads as follows:

<%@ LANGUAGE = "JScript"%>
<!--#include file = "Md5.inc"-->
<%
function Calculatemd5value () {
var pw = "" + Application (Request.Form ("userid"))
PW + + Session ("Sharedvalue")
Return calcMD5 ("" +PW)
}
Clientpassword = Request.Form ("password")
Serverpassword = Calculatemd5value ()
if (Clientpassword = = Serverpassword) Response.Redirect ("Page1.htm")
else Response.Redirect ("tryagain.htm")
%>

The following line indicates that the file Md5.inc (on the server side) is included in the checkpassword.asp script:

<!--#include file = "Md5.inc"-->

This file is the file md5.js between the ASP's <% and%> tags. Standard ASP languages are all with the INC suffix.

Another server-side script describes the Calculatemd5value () function. The field Request.Form ("userid") returns the user name entered when the user submits the form. The true user password value is found in an application variable by the returned user name. (If you plan to use ASP, you might want to use an alternative approach that allows the script to get the password in other ways.) ) Use the PW variable to store the user's password. Retrieves the original random value sent to the user from the session variable and attaches to the user's password. The function then computes the user's password with the random value appended and returns the resulting result.

function Calculatemd5value () {
var pw = "" + Application (Request.Form ("userid"))
PW + + Session ("Sharedvalue")
Return calcMD5 ("" +PW)
}

The core part of the user authentication process is performed by four lines of code, all four lines using the Calculatemd5value () function. The user-submitted MD5 password is classified as a "client password" (clientpassword) variable, and the value computed by the server is classified as a "server password" (serverpassword) variable. Compare the two values. If the two values match, the user's browser will open page1.htm, which is the home page of the write-protected Web application. If the two values do not match, the user's browser opens the tryagain.htm and the user is told that the login failed and needs to log on again.

Clientpassword = Request.Form ("password")
Serverpassword = Calculatemd5value ()
if (Clientpassword = = Serverpassword) Response.Redirect ("Page1.htm")
else Response.Redirect ("tryagain.htm")

To make this script, just define page1.html as the home page of the Web application that you want to write protection on. If you don't use ASP, then you need to translate the ASP code into the language you use in your server-side scripting environment.