From PHP, you can access the useful cURL Library (libcurl) to make requests to URLs using a variety of protocols such as HTTP, FTP, LDAP and even Gopher. (If you’ve spent time on the *nix command line, most environments also have the curl command available that uses the libcurl library)

In practice, however, the most commonly-used protocol tends to be HTTP, especially when using PHP for server-to-server communication. Typically this involves accessing another web server as part of a web service call, using some method such as XML-RPC or REST to query a resource. For example, Delicious offers a HTTP-based API to manipulate and read a user’s posts. However, when trying to access a HTTPS resource (such as the delicious API), there’s a little more configuration you have to do before you can get cURL working right in PHP.

The problem

If you simply try to access a HTTPS (SSL or TLS-protected resource) in PHP using cURL, you’re likely to run into some difficulty. Say you have the following code: (Error handling omitted for brevity)

// Initialize session and set URL.
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);

// Set so curl_exec returns the result instead of outputting it.
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

// Get the response and close the channel.
$response = curl_exec($ch);
curl_close($ch);

If $url points toward an HTTPS resource, you’re likely to encounter an error like the one below:

Failed: Error Number: 60. Reason: SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

The problem is that cURL has not been configured to trust the server’s HTTPS certificate. The concepts of certificates and PKI revolves around the trust of Certificate Authorities (CAs), and by default, cURL is setup to not trust any CAs, thus it won’t trust any web server’s certificate. So why don’t you have problems visiting HTTPs sites through your web browser? As it happens, the browser developers were nice enough to include a list of default CAs to trust, covering most situations, so as long as the website operator purchased a certificate from one of these CAs.

The quick fix

There are two ways to solve this problem. Firstly, we can simply configure cURL to accept any server(peer) certificate. This isn’t optimal from a security point of view, but if you’re not passing sensitive information back and forth, this is probably alright. Simply add the following line before calling curl_exec():

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);

This basically causes cURL to blindly accept any server certificate, without doing any verification as to which CA signed it, and whether or not that CA is trusted. If you’re at all concerned about the data you’re passing to or receiving from the server, you’ll want to enable this peer verification properly. Doing so is a bit more complicated.

The proper fix

The proper fix involves setting the CURLOPT_CAINFO parameter. This is used to point towards a CA certificate that cURL should trust. Thus, any server/peer certificates issued by this CA will also be trusted. In order to do this, we first need to get the CA certificate. In this example, I’ll be using the https://api.del.icio.us/ server as a reference.

First, you’ll need to visit the URL with your web browser in order to grab the CA certificate. Then, (in Firefox) open up the security details for the site by double-clicking on the padlock icon in the lower right corner:

Then click on “View Certificate”:

Bring up the “Details” tab of the cerficates page, and select the certificate at the top of the hierarchy. This is the CA certificate.

Then click “Export”, and save the CA certificate to your selected location, making sure to select the X.509 Certificate (PEM) as the save type/format.

Now we need to modify the cURL setup to use this CA certificate, with CURLOPT_CAINFO set to point to where we saved the CA certificate file to.

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);
curl_setopt($ch, CURLOPT_CAINFO, getcwd() . "/CAcerts/BuiltinObjectToken-EquifaxSecureCA.crt");

The other option I’ve included, CURLOPT_SSL_VERIFYHOST can be set to the following integer values:

• 0: Don’t check the common name (CN) attribute
• 1: Check that the common name attribute at least exists
• 2: Check that the common name exists and that it matches the host name of the server

If you have CURLOPT_SSL_VERIFYPEER set to false, then from a security perspective, it doesn’t really matter what you’ve set CURLOPT_SSL_VERIFYHOST to, since without peer certificate verification, the server could use any certificate, including a self-signed one that was guaranteed to have a CN that matched the server’s host name. So this setting is really only relevant if you’ve enabled certificate verification.

This ensures that not just any server certificate will be trusted by your cURL session. For example, if an attacker were to somehow redirect traffic from api.delicious.com to their own server, the cURL session here would not properly initialize, since the attacker would not have access to a server certificate (i.e. would not have the private key) trusted by the CA we added. These steps effectively export the trusted CA from the web browser to the cURL configuration.

More information

If you have the CA certificate, but it is not in the PEM format (i.e. it is in a binary or DER format that isn’t Base64-encoded), you’ll need to use something like OpenSSL to convert it to the PEM format. The exact command differs depending on whether you’re converting from PKCS12 or DER format.

There is a CURLOPT_CAPATH option that allows you to specify a directory that holds multiple CA certificates to trust. But it’s not as simple as dumping every single CA certificate in this directory. Instead, they CA certificates must be named properly, and the OpenSSL c_rehash utility can be used to properly setup this directory for use by cURL.

I’ve written about Eclipse and how useful it can be, with its extensible plugin-based system. It’s so useful that I use it everyday for almost any language – Java, PHP, JavaScript to name a few. It’s even great for things like CSS and XHTML.

PHP is currently my favourite “hobby” language and has been for some time. While I like PHP, one of the things that hasn’t been straightforward with it is setting up a proper debug session, where you can step through code. This contrasts heavily with a language like Java, which has always had strong developer tools. This has resulted in a mass of third-party tools aimed at facilitating PHP debugging. A while ago, a reader emailed me asking about this very topic, so I decided to put together how-to detailing my experience with the topic and how I went about learning it.

Xdebug for PHP and XAMPP

The debugger I’ll be using will be Xdebug. Because PHP provide no built-in debugging tools, there are many third-party options for debugging. (See the “Debugging Tools” section of this article for more) However, Xdebug seems to be one of the more popular ones, and Eclipse PDT already has support for it.

This guide also assumes use of XAMPP, the great all-in-one solution for quickly setting up a web development environment and to get your code running on the server. XAMPP is great for hitting the ground running, though you’ll probably not want to use it in a production environment – though you likely won’t be debugging there either. Nevertheless, the instructions provided here should work even if you’ve setup Apache and PHP separately on your own.

Getting started

The first thing you’ll want to do is head over the Xdebug page and download the appropriate Zend extension of Xdebug corresponding to the version of PHP you’re running. Save the file into your PHP extension path/folder. Now you’ll have to edit your php.ini file to begin using the plugin. The plugin basically exposes or provides an interface for the client debugger (running in Eclipse or your IDE) to attach to the server and debug/trace through the code that’s running on it. If you’re from the Java world, you’ll know this as “remote debugging”, which is provided by most J2EE application servers.

You’ll also want to have downloaded Eclipse PDT have that installed as your IDE, if you haven’t already done so. Zend Studio for Eclipse also works, since it’s based on Eclipse PDT, and offers quite a few more features, out of the box.

Setting up Xdebug

You should have already saved the Xdebug extension DLL file to your PHP extension folder. Record down the full path of it. Now, open up your php.ini file and go down to the [XDebug] section, or create it if it’s not there. Uncomment or add the following lines:

;; Only Zend OR (!) XDebug
zend_extension_ts="D:\XAMPP\php\ext\php_xdebug.dll"
xdebug.remote_enable=On
xdebug.remote_host="localhost"
xdebug.remote_port=9000
xdebug.remote_handler=dbgp

The zend_extension_ts should point to location of your Xdebug extension DLL that you downloaded earlier; modify as appropriate.

Then, you should disable the Xdebug entry in the list of dynamic extensions. This is confusing, but since we are already setting up Xdebug as a Zend extension, we don’t need another entry. Disable the Xdebug dynamic extension by ensuring the following line is commented out, like below:

;extension=php_xdebug.dll

There is one last very important step you need to do, particularly if you are running XAMPP. Current versions of Xdebug are incompatible with the Zend optimizer that is enabled by default in XAMPP, so you must disable that if you want Xdebug to work. If you don’t, you’ll notice that Apache will crash every time you try to load it with Xdebug enabled. To disable the Zend optimizer, find the [Zend] section in php.ini and comment out all of the entries under it, like so: (This is an example, there may be more to comment out)

[Zend]
;zend_extension_ts = "D:\XAMPP\php\zendOptimizer\lib\ZendExtensionManager.dll"
;zend_extension_manager.optimizer_ts = "D:\XAMPP\php\zendOptimizer\lib\Optimizer"
;zend_optimizer.enable_loader = 0
;zend_optimizer.optimization_level=15
;zend_optimizer.license_path =

You should be able to start Apache now without troubles.

Configuring Eclipse for PHP debugging

The next part will be configuring Eclipse as a debugging client. Since the code will be executing on the web server (Apache), you’ll need Eclipse to “hook in” using the Xdebug protocol. Thankfully, configuring Eclipse is fairly straightforward.

Open up Eclipse’s preferences and go to PHP -> Debug, and ensure that XDebug is selected as the PHP debugger. This sets the default for debugging sessions and lessens the configuration required for each debug session. You can also make sure that the default web server is localhost if that’s the case, which it’ll likely be for a lot of people doing development.

Note that if you are running Zend Studio, you’ll need to follow the steps in this article to enable Xdebug support. It seems that some versions of Zend Studio by default disabled support for the Xdebug plugin in lieu of their own Zend Debugger.

Now you can select a file from a project you’d like to debug. In my case, I’ve selected src/demo/index.php from my Challenge-Response PHP Login System project. Open the file, and then go to the Run Menu and select Debug Configurations… or Open Debug Dialog.

Double click the the “PHP Web Page” entry on the left side bar to create a new debug profile. Here, I’ve named it “CHAP-PHP”. You should see a dialog like the one above. Make sure the “Server Debugger” is again set to Xdebug and that the PHP Server is set to the localhost configuration you set up previously.

Then you have to select the file you want to debug. Click on “Browse”, and you’re confusingly taken to another view of your Eclipse projects; simply select the same file as before – you have to select a specific file, and not just a project or folder.

After that, you’ll need to adjust the URL mapping. You’ll probably need to uncheck “Auto Generate”, and then enter the URL that corresponds to the PHP file you’re debugging. Here, I’ve manually entered /projects/CHAP/trunk/src/demo/ as the URL fragment that triggers execution of the script.

If you want the debugger to stop right at the first line to allow you to immediately begin stepping through code, check “Break at First Line”. (It may be checked by default) Otherwise, uncheck it if you only want the debugger to stop at the breakpoints you’ve specified in Eclipse, which is the normal behaviour most developers will expect.

You should now be able to click “Debug”, and a debug session will launch, opening up the URL you’ve specified and allowing you to step through code. If you don’t like Eclipse using its own internal web browser (which appears just be a front for IE), you can configure which web browser you’d like it to launch URLs with by opening up Preferences and then going to General -> Web Browser and changing the setting to use an external web browser of your choice. Personally, Firefox is my preference.

Start your debugging engines!

You can now get acquainted with stepping through code, which in my opinion, is one of the best ways to learn! When you launch a debug session, Eclipse should prompt you to switch to a new “perspective”, which is just a different layout of Eclipse’s internal windows that many believe better suit debugging through code.

You’re provided with an informative view of the script your currently debugging, along with the highlighted line that execution has paused on. You can set debug breakpoints by double-clicking in the left margin of your source code view window; debug breakpoints show up as blue circles here. The buttons at the top (green “Play”, red “Stop” and others) provide control over execution of the code, allowing you to step through code line-by-line, step into functions/methods and return from them. I encourage you to experiment with all of the controls and get acquainted with the keyboard shortcuts.

Another panel also shows all the current variables available to the script as well as their values. This is useful since you now do not need to echo anything to output or change any of the code to see values.

When you’re done, you can just click the red “stop” button to disconnect from the server and end the debug session. If you’ve completely stepped through a script, you will not be automatically disconnected from the server. Instead, the debug client in PHP will patiently wait to debug the script again the next time it is executed. This is useful to know, since you can just go back to the URL in your web browser and reload the page to trigger the debug session to resume again.

Conclusion

I hope you found this useful, as when I was starting out trying to get a PHP debug session to work, it was somewhat frustrating. As always, I welcome your comments, suggestions and questions below via the comments form!

References

1. Why does xdebug crash apache on every XAMPP install I’ve tried?
2. Xdebug: Documentation
3. How to enable the Xdebug debugger in Zend Studio for Eclipse
4. Debugging PHP applications with Xdebug

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.

Projects using this

• VORG Tool

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.

An online demo of the system is also available.

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.