Here, I’ll try to address some of these concerns and answer some questions.

Salt of the earth

To understand why salting is used, we must first understand exactly what it is. Just like regular salt, in cryptography, salting is used to alter the “taste” or output of some process.

In the case of password storage, most people would realize that you should never store lists of users’ passwords in plaintext, because if that data is ever compromised, attackers will gain access not only the compromised accounts but could potentially use the passwords to gain access to user accounts on other services/sites. This is because people often reuse the same passwords across multiple account/services.

The easiest way to avoid this is to store the hash of the password. A hash is a one-way function, that is, once you compute the hash of a value, you cannot obtain the original from just the hashed value. Some typical hash functions are MD5 or the more secure family of SHA hash functions.

However, this still doesn’t fully conceal passwords. If an attacker were to obtain the list of hashed passwords, they could try a dictionary-based attack to discover the original inputs. This involves hashing common words to see if they hash to the correct value. Since people often use common words or combinations of such, a dictionary-based attack has the advantage of having far fewer combinations that the attacker needs to try compared to a true brute-force attack.

Adding variability

This problem can be mitigated by salting, which basically amounts to combining the password with additional input before passing it into the hash function. This alters the end output from the hash function so that a dictionary-based attack cannot be used, provided the salt is kept a secret. A comparison example:

Without salting:
hash(A) -> B;

With salting:
hash (A + S) -> C;

In the first example, salting was not used before hashing. Assuming the value ‘A’ is a common word or phrase, an attacker can use a dictionary-attack to determine what the value of ‘A’ was. (I.E. what value hashes to the value of ‘C’)

With salting, things become more difficult. If the attacker does not know the value of the salt (S), they cannot use a dictionary-based attack because the actual input will not be a common word or phrase. Instead, they must try all values in the dictionary with all possible values of the salt. In fact, every bit of the added salt value doubles the number of computations in a dictionary-based attack. The important point to retain here is the salt value must be kept a secret in order to obtain this benefit.

One other benefit of salting is to ensure that two accounts with the same password don’t produce the same hash. This can be accomplished by making different accounts have different salts. The obvious benefit of this is to decrease the information leakage from the hashes, as otherwise, equivalent hashes would infer equivalent passwords.

Salting and the modified Challenge-Response System

With the modified challenge-response system, it isn’t clear to me how salting could be used to improve it. Here’s a quick re-cap of how it works:

Signup:

1. Server sends random1
2. Client sends hex_sha1(hex_hmac_sha1(password, random1))

Login:

1. Server sends random1 and random2
2. Client sends hex_hmac_sha1(password, random1) and hex_sha1(hex_hmac_sha1(password, random2))

To login, the user must present two values: One to verify that they know the password, and the second value, which is used to set the response that must be computed for the next login.

Because the client must compute the next response value, it’s a bit tricky to implement salting in a way that’s beneficial.

One possible method would be to further hash the second value (hex_sha1(hex_hmac_sha1(password, random1))) with a server secret before storing it in the database. This would complicate things should the database be compromised but not the server secret, since a dictionary attack would become much harder with the extra variability of a server secret. In this case, the work flow would look something like this:

Signup

1. Server sends random1
2. Client sends hex_sha1(hex_hmac_sha1(password, random1)) [Let's call this value `hashed_challenge_response` for brevity]
3. Server stores hex_hmac_sha1(server_secret, hashed_challenge_response)

Login:

1. Server sends random1 and random2
2. Client sends hex_hmac_sha1(password, random1) and hex_sha1(hex_hmac_sha1(password, random2))
3. Server computes hex_sha1(hex_hmac_sha1(password, random1)) [Call this `hashed_challenge_response_received`]
4. Server checks if hex_hmac_sha1(server_secret, hashed_challenge_response_received) equals the value previously stored. If so, authentication was successful and a new challenge-response is stored based on the second value received.

Note that this method would not improve the login security anymore, since an attacker who captured the intermediate traffic of a successful login could still conduct an offline dictionary attack, which this challenge-response system is unfortunately susceptible to.

However, the modified system does benefit from the use of the `random1` and `random2` challenge strings, which are stored alongside the response values. Since these are random and different for each user (and for each subsequent login), accounts with the same password will not have the same hash-response. This effectively gives the second lesser benefit of salting.

The modified challenge-response system also suffers from the inability of the server to enforce strong passwords. Because the initial value sent during registration is a hashed value of the password and a random value, the server cannot be aware of any properties of the password such as its length or composition. The only aspect that could be enforced server-side would be to make sure the password was not blank! My suggestion is to (attempt to) enforce password complexity using JavaScript on the client side. Such rules can obviously be circumvented but are better than nothing.

Conclusion

Hopefully I’ve shed some light on the topic of salting in relation to the modified challenge-response Ajax PHP login system. I’m no security expert, so you should not take my advise as scripture. Please don’t hesitate to give me your comments or feedback!

Download the source

Please feel free to download and try out the first public release of the CHAP-PHP login system. The zip file has the full source and provides an example how to implement the system both on the client and server side.

The same demo available in the zip file is also available here.

Improving authentication security with Challenge-Response

Challenge-Response is the basis for many authentication systems. In such a situation, a server may have to authenticate a user by verifying their credentials, usually in the form of a password. However, transmitting plaintext passwords over connections that are not secure can lead to compromises. In such a situation, challenge-response may be used. This usually involves the server sending a random challenge string to the client, which must then produce an appropriate response that can only be computed using the challenge and the password. This response is then sent to the server, which can then verify if the right password was used to generate it. The response is usually computed by hashing a value that depends on the challenge and the password, thus it is not possible to obtain the password from the response, which might have been sniffed on an insecure connection.

However, such a traditional challenge-response has the downside that the plaintext password (or a password-equivalent) must be known to the server at some point. Paul Johnston came up with an idea for an alternative system a while ago that overcomes these shortcomings. (Though it is not free from weaknesses itself) It is this “Alternative System” that the above release is based upon. Here is a quick explanation of the system, adapted from Johnston’s site:

Signup:

1. Server sends random1
2. Client sends hex_sha1(hex_hmac_sha1(password, random1))

Login:

1. Server sends random1 and random2
2. Client sends hex_hmac_sha1(password, random1) and hex_sha1(hex_hmac_sha1(password, random2))

During registration, the value sent by the client is stored. During login, the user must present a value that when hashed produces the value provided at registration. Because of the non-reversibility property of hashes, knowing the value passed during registration does not allow an attacker to login. The only way to produce the valid response is to know the actual plaintext password, which is never transmitted or known by the server. In this system, challenges are linked to a user and must be stored, since it must be known what challenge was used to produce the response.

The second random challenge (random2) and the second value sent by the client during login are used to prevent replay attacks. Upon successful login, the second value provided by the client becomes the next response, equivalent to the value first provided during registration. Thus, for the next login, the value that is sent must hash to equal this value. This also means that the challenges are updated/changed each time a login is successful. This has the unfortunate downside of revealing when a user has logged in, since the challenge presented at login will be different. (Challenges must be publicly available)

For a more thorough explanation, I suggest that you read Johnston’s article on the subject.

Getting it to work

Understanding the process above leads to the conclusion that user-login is now a two-stage process. Since the challenges are tied to a user, the username must first be known to the server in order to retrieve the challenge for that user. The client can then use the challenge to produce the response to send to the server for authentication.

Having a two-stage login form would be very unfriendly to users. Thus, the main challenge is to make it appear as if nothing out of the ordinary is happening. This is where Ajax comes into play. When the form is submitted, the event is prevented from occurring normally. Instead, the username is first retrieved from the form and sent to the server via an Ajax call in order to retrieve the associated challenge. Once the challenge is received, the appropriate responses are computed, inserted into the form and then the form is submitted.

The current system also works in the case that JavaScript is not enabled/available on the client side. In this case, challenge-response will not be available, since JavaScript is used to compute the responses. The server-side PHP scripts infer that JavaScript was not enabled on the client-side if proper challenge-responses are not received, and thus treat the password as plaintext. In this case, passwords are transmitted in plaintext. With this code, you have the choice of allowing this “insecure” login to proceed or not.

Note that the CHAP-PHP is more of a module than a full-fledged system, since it’s not intended to be used on its own but instead as part of some application. It might be a bit confusing if you’re a non-developer, but I’ve tried to make it as straightforward and simple as possible so that it will be easy to integrate with existing code bases/frameworks/sites.

Please don’t hesitate to contact me with your questions, comments or suggestions.

Disclaimer and warning

You should not use this as the basis for authentication for sensitive data/websites. I am not a security expert. At this point, this is more of a proof-of-concept then something concrete. It is intended to be the starting point for perhaps something more secure and to show that there are alternatives for more secure authentication when SSL is not available.

Revision History

• 0.5 - First Public Release - 2008-03-29
• 0.5.1 - Fixed file-based storage to be more robust - 2008-03-30

While this lack of security surprised me, what further surprised me were the number of people throwing their arms up, and saying, “Oh well, this is unpreventable when you’re not using SSL (https) for your client-server connection“. Contrary to popular belief, it is possible to implement a login or authentication system that doesn’t transmit passwords in plaintext and thus is more secure over unencrypted channels - it’s called a CHAP login system, and it vastly improves security.

They’re listening

The basic problem with communication over the Internet is that it is inherently insecure. Eavesdropping is quite easy, especially if one has knowledge of how the packets or traffic are being sent from a host to a server and vice-versa - this has to do with how most of the networks that comprise the Internet are setup. This presents a problem during the process of authentication, that is, determining that a user really is who they purport to be.

Authentication usually takes the form of a user providing credentials, that is, a set of information that proves their identity. For most applications, this consists of a username-password combination, which provides both the identity (username) and proof (password). The password is proof of the user’s identity since it is supposed to be kept a secret. But, if the password is transmitted over insecure channels, how can it be kept a secret?

CHAP and Digest Access Authentication

This is where CHAP (Challenge-Response Authentication Protocol) comes into play. Despite my main focus being on web applications (built using server-side scripting languages), methods like this such as Digest Access Authentication have been around for some time. Digest Access Authentication is a function provided by the web server itself (though the client browser must support the method as well), and is a way to password-protect resources (i.e., certain web pages or directories) so that only certain users can access it. The previous Basic Authentication Scheme, merely transmitted both the login and username after encoding in base-64, providing no protection whatsoever from sniffing.

Hash functions

So, how does it work? At the heart of CHAP are functions known as hash functions . Ideal hash functions are one-way, that is, if one knows the output of the function, it is impossible to determine the input. One output could potentially correspond to an infinite number of inputs. How can this be so? Think of functions involving modular arithmetic - if I tell you that the remainder of a division was 3, can you come up with a definitive answer as to what the intial two inputs were? It could have been 15 mod 4, but it could have just as easily have been 16 mod 13 . Actual hash functions are more complicated than this.

Another important property is that different inputs should produce different outputs - the previous example did not illustrate this. To some extent, this property can only be idealized, since the output from hash functions are usually strings with limited lengths, and thus there are only a finite number of outputs while there are usually an infinite number of inputs. Thus, a good hash function should try to avoid these collisions, that is, when two inputs produce the same output, and should definitely make it hard to intentionally produce collisions.

Bringing it together

Perhaps you can see how hash functions would be ideal in this situation. For example, a password, once put through the hash, would produce an output that could still be used for authentication, but it would be impossible to go from this back to the original password. But, CHAP takes it one step further.

When a user wants to authenticate, the server first generates and issues a random challenge string to the client. The client then combines this with the password using HMAC, (a cryptographically proper way to combine information with a key/password), then feeds this result into a hash function. The output from the hash function is then submitted to the server. When the server receives this string, it also does the same computation (since it keeps hold of the challenge string and also has the user’s password), and compares this with what it received from the client. If the two match, then authentication was successful and the user can be given access!

How is this better than transmitting the password in plaintext? Let’s say someone, named Eve, is sniffing the traffic from client to server. What information would she get? Well, first, she’d get the challenge string issued from the server to the client. Then, she’d get the output from the hash function sent from client to server. Why can she not derive the password from this? Because hash functions are one-way, there is no way to go back original input data - which contained the password combined with the challenge string.

Hold on, partner

While this sounds simply, there are many implementation issues. Firstly, the client must have access to hash functions. For the most part, this is trivial, as the client application is usually a web browser, and most web browsers support JavaScript, which can be used to implement several popular hash functions. See Paul Johnston’s excellent page on cryptography in JavaScript for more details.

Another important point is that the challenge strings issued by the server must be random and must not be reused. If they were reused, our attacker Eve could sniff the output from the client’s hash function and just re-send that to trick the authentication scheme as the same challenge string and password fed into a given hash function will always produce the same output. Therefore, there must be a way to keep track of the challenge strings used or at least make it very unlikely for the same challenge string to be used more than once.

Also, the technique is not totally secure. (But what is?) An attacker could capture the output from the client’s hash function and using brute force attacks (trying almost every combination), attempt to guess the user’s password, by trying to find out what would produce the hash function’s output. This has the added danger that the attacker doesn’t need to communicate with the server for this sort of attack, negating any server-side lockout protection that may be in place. A remedy for this, is of course, strong passwords, but not a lot of people use them.

Additionally, a multi-user system would need to keep track of challenges issued to each user, instead of relying on the client to tell the server what challenge was issued to it. This must be done since mutiple users could be authentication at or around the same time, so the server would need to know what challenges were issued to which user. If the usernames and passwords are stored in a table, this could easily be done by adding another column for the challenge.

The tricky part here is that now the server needs to know the username before it can issue the challenge. This could be done in a two-step process, but might be confusing to some users. Here is where I think Ajax could come into play - using Ajax techniques, you would be able to accomplish this two-step process using a normal form and mask it to appear as a regular one-step login process.

Another issue that needs to be dealt with is that the way this system has been currently described, the passwords are stored in plaintext on the server. This is a big no-no, as if the server is compromised, the attacker now has a plethora of username/password combinations. Since users often re-use passwords across many different sites (despite warnings not to), some of which may have sensitive financial information, this could lead to more complicated matters, such as identity theft. One solution is to store a hash of the password plus a salt value, and then also adjust the client-side method for computation of the challenge-password hash accordingly. This doesn’t improve the security of the system, but it does prevent passwords from being discovered should the server be compromised.

Another problem is what occurs when the client doesn’t have JavaScript enabled. You could simply disallow logins, or “downgrade” the system to submit plaintext authentication creditials in this case. This wouldn’t be hard to do.

All this talk, but no action

So far, all I’ve done is given a few examples of how a CHAP system might work - I’m definitely no expert on this subject. In a later article, I hope to present an actual implementation, (using PHP and MySQL on the server side and JavaScript on the client side) and also deal with how to track the login session - stay tuned. If I’ve piqued your interest, please don’t hesistate to check out the references below.

References

1. Paul Johnston’s page on JavaScript Cryptography - an all-around excellent resource
2. Simon Willison on MD5 in JavaScript
3. Apache Module: mod_auth_digest