This made it somewhat tedious to decode them, as the only way to get the original list of points was to create a GPolyline and then pull out the points from that object. This is not ideal since the work must always be done on the client side with JavaScript and using Google Maps.

To solve this, I quickly ported the algorithm over to PHP from the JavaScript source. Please feel free to download/modify/use this script.

Since the encoded polyline format offers numerous benefits (and because I had data already stored in this format) I did not want to move away from it. At the same time, I needed access to the points for working with things like Google Static Maps, which curiously does not accept the encoded polyline format for displaying paths. (Probably to reduce resource usage on their end, since decoding takes CPU time)

Thankfully the polyline decoding algorithm was already available at Mark McClure’s site. I spent a few minutes understanding the process and porting it over to PHP. The source is attached above and is released under an MIT license. Basically, the only change I had to make was to use some PHP functions to convert characters to their ASCII code, since PHP doesn’t have a charCodeAt() function.

Please let me know if you find it to be useful.

I’m currently using CakePHP and finding it to be quite useful. The “automagic” handling of tables is useful for basic relationships, though more complicated setups usually require manual work. The MVC implementation has also clearly drawn inspiration from Ruby on Rails, which may be advantageous to some, though this has no bearing on me. Though there are a few things that nag me about CakePHP (such as lack of a good testing suite, though that’s supposedly fixed in 1.2, which really should be marked as version 2.0), overall it’s a great framework that adds badly-needed structure to PHP and has saved me time.

One thing I’d like to see, however, is a proper exception handling model. I realize this would require making it PHP 5-only, but in my opinion, PHP 5 adds some sorely-need features, such as the aforementioned exception handling model and a class/object system more in line with other languages.

Signaling intent

I’ve written about the benefits of exception handling before, so I won’t delve into those details again. In short, using exceptions is a better way for a method to signal to a caller that something went wrong rather than just returning a special/reserved value as an error code.

In particular, saving of models would benefit from this. Currently, if you want to check if the model was saved properly, you have to do something like this:

if ($this->ModelName->save($this->data))
{
  // Model saved properly, can continue normally here.
  ...
}
else
{
 // Model did not save properly.
}

It’s a little bit kludgy, but isn’t actually that bad since Cake simplifies form validation a lot with the HTML helper in views. You can simply put something like $html->tagErrorMsg('Post/title', 'Title is required.') in your view to display that error message when a particular field does not validate. This removes a lot of the tedium out of making your forms return proper error messages in situations with bad input.

Exceptional cases

However, in some situations you might want to execute your own logic when a call to Model::save() fails. In this case, having that method throw a proper exception would allow the error to be propagated to the controller nicely and would remove the need to make a call to Model::invalidFields() to get the reason.

Coming from a Java background, this makes more sense to me, since I consider its exception handling model to be one of the language’s strong points. It has numerous benefits to improving readability and maintainability of code.

However, there are some drawbacks, since this requires the use of PHP 5. As CakePHP is designed to be PHP 4 and 5 compatible, exception handling is really not an option. However, since PHP 4 is so old, I’d eventually like to see a move to PHP 5, especially for its better OOP model and exception handling. Additionally, PHP 6 is just around the corner, so I don’t really see a need to stick with PHP 4 for that much longer.

Additionally, if you’re just saving one model (as the result of a form submission) it doesn’t really make sense, nor is it necessary, to have exception handling since CakePHP already takes care of displaying error message for the invalid fields:

// Controller:
...
if ($this->Post->save($this->data))
{
  $this->flash('Your post has been saved.','/posts');
}
...

// View:
...
<?php echo $html->input('Post/title', array('size' => '40'))?>
<?php echo $html->tagErrorMsg('Post/title', 'Title is required.') ?>
...

In the above example, taken from CakePHP’s own blog tutorial, you don’t really need exception handling since the appropriate actions are automatically handling by Cake. If the save succeeds, a positive message will be displayed and the user forwarded on. Otherwise, the controller proceeds to render the given view, where $html->tagErrorMsg displays the given error message if the associated field was marked as invalid by the model during the save attempt.

For more complicated situations where you’re saving multiple related models in a single controller action, exception handling would be helpful in reducing the number of branches, since you wouldn’t need to have so many if ... else blocks muddling up the flow of the code. However, it’s not straightforward to integrate this into Cake, since for most of the time, people won’t need the exception handling capability if they’re just doing a simple save as outlined above.

The easiest way I see of accomplishing this is to define your own method that wraps around the existing Model::save() method so that proper exceptions can be thrown. This would, of course, create confusion as then there would be two ’save’ methods.

All things considered, Cake is still a strong framework, so I will continue using it. For all the slight concerns I have, it’s still very much beneficial to me. If there’s one more thing I could ask for from Cake though, it would be for better documentation! Maybe I should start contributing…

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

* Sensationalist headline inspired by previous posts

Eclipse is my IDE of choice, as you’l probably have noticed from some of my previous articles. I had been wanting to write an article about why I use it (and why I switched to it), but kept putting it off. Recently, Matt Mullenweg wrote about his problems with Dreamweaver, and this perhaps prompted me to organize my notes on why I’ve chosen to use Eclipse. Don’t get me wrong - I’m not advocating that you immediately switch and throw out your current editing tool (the headline above, as noted, is purely for sensationalism) - but rather I’m just urging you to consider Eclipse for your next project.

Changing Gears

Like many, before switching to Eclipse I had been using a pure text editor, Ultraedit, for most of my web-development activities. Ultraedit seemed fine for most things, offering basic features like code highlight and autocompletion. However, it lacked a certain finesse when it came to dealing with larger projects. For example, if you’d defined a class, its members wouldn’t be available for autocompletion. Something else was needed. I finally decided to take the plunge, and switch over to Eclipse for all my development towards the end of the summer last year.

Some might wonder why I was even using a text-editor in the first place for development. For those coming from a traditional programming/development background, the idea of not using an IDE (Integrated Development Environment) is silly. This is because a lot of programming languages are compiled, and in this case, it just makes sense to use an IDE since it’s easier to write code, compile and debug using one tool instead of multiple ones.

However, for scripting languages, especially those meant to run on a web server, one can “get away” with not using an IDE quite easily. This is because the scripts are not run standalone but are almost always executed in the context of a web server; thus you’re usually editing code that you then run on a development web server, without the need for a special tool like a compiler. Additionally, it’s easy to view the output using any web browser. These reasons are what allowed me to persist in using a text-editor for so long.

No turning back

However, once I started using Eclipse, I was hooked. I downloaded Eclipse PDT (PHP Development Tools), which is basically a version of Eclipse bundled with the tools/plugins necessary for setting up a PHP development environment. Besides offering everything Ultraedit did, it also offered nice features like easy ‘Todo’ lists, (just type ‘todo’ anywhere in a comment and it’s automatically indexed by Eclipse into a list), code completion for built-in PHP functions and your own as well as a multitude of other advanced features that IDEs have. Oh, and it’s also FOSS. (Free and Open Source Software)

However, perhaps the best part about Eclipse is its robust and well-supported plugin system. This allows Eclipse to pretty much assume any feature that someone is willing to write a plugin for. This is what really sold me on Eclipse, because this almost makes its abilities endless. Some of the plugins I use are Subclipse for SVN integration, Mylyn for Trac integration and JSEclipse for JavaScript editing. This is part of the reason why Eclipse is the basis for many other IDEs out there.

Some other nice features are the ability to link the IDE in with the Zend Debugger, thus allowing for proper debugging sessions with PHP.

Spoiled

However, I’ve been pampered somewhat and have found a few things to complain about, at least when it comes to Eclipse PDT. I use Eclipse JDT (Java) a work and its advanced refactoring abilities are a feature I find myself wanting in the PDT version. Have you ever found yourself wanting to rename a variable to something more descriptive but putting it off because you’re afraid you’ll mess something up by forgetting to change the name somewhere?

With some IDEs, you’re left having to just do a search-and-replace in order to accomplish what should be a trivial name refactor. Even if your editor supports regex searches, things can still be tricky - what if you’ve used the same name, but in a different context, and thus shouldn’t change the variable there? The point is, the process still has to be human-supervised and is tedious. With Eclipse JDT’s advanced refactoring, you can rename the variable once - and the IDE is smart enough to know where else to change it to keep the code consistent - very neat, and I was amazed when I first used it. Other refactoring abilities include extracting methods out of blocks of code in order to clean up lengthy methods. All of this makes your life 10 times easier and allows you focus on real programming rather than annoying tasks.

However, Eclipse PDT doesn’t support this for PHP code, yet. I hear that it may be supported in a later release, so I have my fingers crossed. Perhaps accomplishing these refactoring tasks is easier in Java because of its compiled nature or because the JDT project has received more attention. It’s definitely possible in PHP, as some IDEs, such as the Zend Studio (which is based on Eclipse) support this ability. Zend Studio, however, is a commercial solution and I haven’t tried it out yet.

Nothing’s perfect

Eclipse does have its downsides as compared to a traditional text editor. First of all, it’s a memory hog - though most IDEs are. I have regularly seen Eclipse eat up 300-400 MB of RAM if I’ve been using it for a long time. However, it should be noted that I have not had it crash once, so it’s been rock-solid as far as stability goes. Nonetheless, I recommend you to have at least 2 GB of memory if you really want to use it properly, since you’re likely to have other programs open. This is especially important if you’re running Windows Vista. RAM is quiet cheap nowadays, and you can easily pick up 2 GB for $50 or less and upgrading is a painless process, so there’s no reason not to.

Finishing up

Eclipse has changed my life. Okay, so perhaps I’m exaggerating a bit. But, I can say that development, at least for me, would be much harder without Eclipse. If you’re still using a text editor for development, I urge you to give Eclipse a try - just for 30 days, and see how you like it. I don’t guarantee results as good as mine, but you may be pleasantly surprised.