Password Based Authentication Using Message Digests

March 10, 2008February 5, 2010 Atul Kahate 4614 Views 2 Comments atul kahate, Java Articles, user authentication

The question of how best to perform user authentication is a puzzle that is quite tough to solve. While newer techniques keep emerging, the bread-and-butter user authentication technology of passwords will not go away very soon. Usage of passwords for authenticating users raises several concerns, such as how long the passwords should be, using what combinations of letters, digits, special symbols, etc; and also how long should passwords remain valid (i.e. how frequently they should expire), and so on.

Also noticed a strange thing? If a user loses her Internet banking password and calls up the customer service agent number, somehow the person there does not seem to know the user’s password for resetting purposes. All that the person there can do is to reset the password, i.e. to create a new password and mail that to the user. We logically and also correctly think that this must be because the user’s password must be kept secret. However, many times we wonder how this can be achieved.

While several approaches can be used to keep the users’ passwords secret, the most popular among them has traditionally been the usage of message digests of passwords, instead of the passwords themselves. A message digest (also called as hash) must always be unique. In other words, just as a finger-print of any person in this world must be unique, if we compute the digest of any message, it must always be unique. This is depicted below.
This is common sense. Message digests also work in a similar fashion. Given any two different messages (and when we say different, they can actually differ in value even by a single bit!), if we compute their message digests, they must also be different. This principle is quite useful in various applications to ensure integrity of data. However, it has a very interesting usage in the world of user authentication as well, as we shall soon discover. Let us first visualize the idea:

However, we should clarify one difference between human finger prints and message digests. From a finger print, we can reverse-trace the person. From a message digest, it must be impossible to find out the original message.

Message Digests in User Authentication
One of the golden rules of user authentication is that the password of the user must not leave the user’s computer. However, if the password entered by the user does not leave the computer and reach the authenticator (let us say a Web server application), how could the user’s credentials be checked?

Some applications provide a via media. When the user enters the password, they send it to the server, and the server authenticates as usual; except that the password sent from the user’s computer travels over a secure connection (say using the Secure Socket Layer or SSL protocol). Because the entire conversation between the user and the server is encrypted, the user’s password is not visible to an intruder. This is an acceptable scheme of authentication in certain applications.

However, even a better practice exists. Over and above using the SSL protocol for encrypting the entire communication, in this scheme, the password never leaves the user’s computer. Instead, a program running on the user’s computer gets the password, locally computes a message digest of the password, and sends the message digest of the password over the SSL connection to the server. Because of SSL, the message digest of the password is not visible to anyone. Moreover, the actual password does not have to leave the user’s computer. This also has the other advantage that we need not capture and store the user’s password in the server-side user database. Instead, when the user ID is created for the first time, we can just store the message digest of the password against the user ID. Whenever the user wants to log in, the message digest of the password sent by the user’s computer can be compared with the message digest of the password stored in the user database.

This scheme is used in a majority of real-life sites for a number of years now. This should also explain why when we call up a customer service agent, the person does not know our password – it is just not stored in the user database! All that someone can see is the message digest of the password. While this is good enough for launching attacks (after all, one just needs to send the user ID and message digest of the password every time; so knowing the message digest of the password is good enough!), this scheme is certainly not as bad as sending the password out from the user’s computer.

Practical Example
In the following example, an HTML page captures the user’s password, computes its message digest using the SHA-1 algorithm locally, and sends the message digest of the password to the server. A JSP waiting on the server-side computes a digest of a hard coded password and matches it with what the user’s computer has sent. If there is a match, the user is considered to be a legal user. Minor changes in the JSP code will allow us to remove the hard coding of the server-side password, and instead to read the message digest of the password directly from a user database.

sha1.html
<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”>
<html>
<head>
<title>SHA-1 Example</title>
<meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″>
<script type=”text/javascript” src=”sha1.js”></script>

For this to work, we need to download sha1.js from http://pajhome.org.uk/crypt/md5/ Please tak care to read and follow the copyright notice on that site.

<%@ page import = “java.security.MessageDigest” %>

<html>
<head><title>SHA1 Example</title></head>
<body>
<h2>SHA1 Example!</h2>

<%
String browserDigest = request.getParameter(“digestedPwd”);

byte [] browserBytes = browserDigest.getBytes(“UTF8”);
browserDigest = new String (browserBytes);

String serverPassword = new String(“test”);
byte[] serverBytes = serverPassword.getBytes(“UTF8”);

String serverDigest = new String (“”);

try {
MessageDigest sha1 = MessageDigest.getInstance(“SHA1”);

sha1.update(serverBytes);
serverBytes = sha1.digest();

serverDigest = new String (“”);

} catch (Exception e) {
out.println(“Error”);
}

for (int i = 0; i < serverBytes.length; i++) {

byte b = serverBytes[i];
Integer k = new Integer(b);
String s = Integer.toHexString(k.intValue());

if (java.lang.Math.abs(k.intValue()) < 10) {
s = “0” + s;
}

if (s.indexOf(“ffffff”) >= 0) {
s = s.substring(6);
}
serverDigest += s;
}

out.println (“<br />”);
out.println (“Browser password = ” + browserDigest);
out.println (“<br />”);
out.println (“Server password = ” + serverDigest);
out.println (“<br />”);

if (browserDigest.equals(serverDigest)) {
out.println(“Password is matching”);
} else {
out.println(“Password is incorrect”);
}
%>

</body>
</html>

About the author : Atul Kahate is Head – Technology Practice, PrimeSourcing (the The Global IT Services business from i-flex solutions limited). He has authored 16 books on Information Technology, 2 on cricket, and over 1500 articles on both of these in various newspapers/journals. He can be reached at akahate at gmail dot com.