After much speculation yesterday, marked by a leaked web comic and finally an acknowledgment by Google, Google Chrome, the much anticipated web browser, is here.

I encourage you to download it and give it a try, as I did as soon as it came out. Here are some of my initial impressions.

Overview

Google released a fairly long web comic that delves into quite a bit of detail about Chrome - it’s not your typical comic! Touted as being built “from scratch”, Chrome uses the WebKit rendering engine, the same one that powers Safari and Konqueror.

The first thing you notice is how minimal the “Chrome” or UI of Chrome is. If you’re used to a half-dozen toolbars, buttons and widgets all over the place, Chrome will seem like a greenfield to you. By default, there is only a tab bar and then an address bar containing back, forward, a combined reload-stop button and the address bar. There are also buttons for bookmarking a site and for page and browser settings. The bookmarks bar is not displayed unless you specifically change that setting.

Keyboard shortcuts are also present so that you don’t have to click through context menus. If you’re used to the keyboard shortcuts of Firefox and IE7 you’ll be pleased to know that most of them transfer over without change: Ctrl-T opens a new Tab, Ctrl-W/Ctrl-F4 closes a tab, Alt-D focuses the address bar and Ctrl-J opens Downloaded Files.

The address bar also functions as a search bar, and this combination just makes sense. It’s something I’ve always been doing using Firefox Quick Searches

By default the home/start page is set to set to show an Opera-style “Speed Dial” page containing most recently-accessed pages/bookmarks. You can also configure Chrome to restore the previous tabs/websites on startup, which is my personal preference ever since I started using Firefox.

Features

Chrome integrates Google Gears to speed up supporting web applications and is an obvious effort by Google to self-promote. This is substantial since the download link for Chrome is on the main Google search page - no small feat considering only the most popular/important services get that sort of attention and furthermore the link is positioned dead center beneath the search field.

The address/search bar

Chrome allows for quasi-Site-Specific Browsers by use of “Application Shortcuts”, which can be set for any website but are meant to be used mainly with web applications. These allow you to open the target URL in a browser window that does not have the menu or address bars and essentially serves as a blank canvas upon which the web application’s own UI can be displayed.

This is similar to other SSBs such as Mozilla Prism or Fluid for the Mac, as they aim to bridge the gap between desktop and web applications to make their integration more seamless.

However, like Google Blogoscoped points out, using such non-browser interfaces may condition the user to be more lax when entering their credentials and makes phishing attempts more viable since no URL is displayed. This is curious since security, “sandboxing” and general safe browsing were so high on Chrome’s feature list - this feature seems to help undo some good user practices of always confirming the URL before entering credentials.

There are also some nice little enhancements as well - the combined address bar/search bar is very much like Firefox 3’s “awesome bar”. Chrome also allows you to dynamically resize any textarea element, without the site designer having to code this specifically in JavaScript or some other client-side technology.

Performance

Each tab/window is a separate process and thus will show up separately in Task Manager; Chrome also offers its own Task Manager but the memory usage reported here differs from that in the Windows Task Manager. To get the full picture, you have to click on the “Stats for nerds” link, which takes you to about:memory

This page displays the full memory usage details, and also, surprisingly, displays memory usage for any other web browsers also currently running! (I have confirmed that it will display Firefox 2/3, IE7 and Opera 9)

Much talk has been made of this feature; indeed while it does use more resources, it also prevents a single site from bringing down the entire browser as only that tab/window will be affected. To test this out, just terminate one of the instances of chrome.exe and you will see that tab’s screen into a “sad tab of death” with an amusing message.

JavaScript

Though JavaScript falls under the category of `Performance` I felt it deserves its own section because of the importance of JavaScript in web applications. Chrome uses the Google-developed V8 JavaScript engine, which has also been released as open source.

The main points of V8 are outlined at the Google Code page for the project, and are quite interesting. One of the main improvements in performance is the use of a Virtual Machine (VM) for processing JavaScript.

The V8 Virtual Machine is different from say, the JVM (Java Virtual Machine) in that it compiles JavaScript source directly to machine code; there is no intermediate byte-code representation used and hence no interpreter is needed for this. This seems to indicate that JavaScript performance might be faster on Chrome since there’s no intermediary. Google provides some benchmarks to confirm this.

From some informal/unscientific preliminary testing, the V8 JavaScript engine in Chrome does appear to be quite fast; loading the same Digg topic in Firefox took longer than it did in Chrome. (Roughly 14 secs vs. 8 seconds over a few trials - and Chrome did not have the benefit of AdBlock Plus) I’d be very interested to see how Chrome stacks up against Firefox 3.1, considering the rumoured performance boosts coming with it.

If Chrome has anything going for it, it’s definitely the lightning fast JavaScript performance. Coupled with the crash-proofing this makes it ideal for use in web applications.

Development

Chrome comes with a nice DOM inspector reminiscent of Firebug. Using it is dead simple; you just right click and select “Inspect Element” and the inspection window will pop up with the element highlighted. Here you can see the full DOM tree as well as the computed CSS styles for the element.

There’s an included JavaScript console for executing code/commands/expressions on-the-fly and while there is a JavaScript debugger included, it seems at this time to be a command-line only tool, far less user-friendly than Firebug.

Not ready for prime time yet?

Of course, Chrome is marked as Beta by Google, something we’ve come to expect since Gmail has been in beta for longer than the company has been publicly traded. Nonetheless, there are still some features that are sorely missed.

The one thing I absolutely love about Firefox is the vibrant developer community and subsequent widespread availability of quality, useful extensions. This has produced such gems as the aforementioned Firebug and Adblock Plus.

For now, extensions/addons are not part of Chrome but may be added in a later version. In the meantime I don’t think I’ll be even close to ready to switch, as I’m very stubborn. I don’t use that many extensions but the few that I do are “must-haves” and I just can’t browse without them.

Lastly, there are always privacy concerns, especially from a company as big an involved as Google. Though you can turn off the sending of usage statistics, there will always be some with their tinfoil hats on.

Conclusions

All things considered, Chrome is a very good entry into the browser market. While I don’t think it’s ready to take on Firefox or IE yet, it does provide competition. So as long as Chrome continues to support standards (which I think it will, since it uses the WebKit renderer and Google has also been forthcoming with their support for web developers), I won’t have a problem with it. I won’t be switching over to it anytime soon, but at the very least it’ll be a useful development tool to verify/test my websites on to make sure they look proper in Safari/Konqueror/Chrome.

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

Credit where credit’s due

To its credit, the W3C has done a lot of great work. Headed by Tim Berners-Lee, the creator of the web, it’s done good work in standardizing the data formats that encompass the Internet. Without some sort of guiding body, the web would certainly be a lot less usable than it is today. They’ve also made decent progress in updating standards as technology/trends change, and haven’t left out accessibility for the sensory-impaired, something that should be lauded.

Certainly attempting to standardize something as widespread as HTML/XHTML across something as big as the Internet is no easy task; working with the companies making the browsers must have been a hard task. After all, companies want to distinguish their product from the others; if they all support the same “standards”, what would make one better than the other? Perhaps this was the thinking during the browser wars when companies started introducing support for non-standard elements in order to make their browsers more appealing to users and web designers.

Part of this is the reason why some pages still render differently in IE than in Firefox or Opera. But these days, it’s mainly IE6 that’s the odd one out, with Firefox and Opera (among others) either supporting the W3C standards better or completely.

Competition breeds innovation

While this effort by browser makers to independently make their own specifications often (especially in the past) resulted in broken web pages that only worked in certain browsers, once in a while, it provided browser programmers the ability to introduce a new feature that was actually of use, besides something like the marquee tag.

What I’m talking about is the XMLHttpRequest object, the basis for Ajax and hence a lot of the websites or web applications that you may use on a regular basis. If you’ve used Gmail, if you Digg, or if you use the new Yahoo!, you’ve benefited from Ajax and hence this non-standard web technology. While the original concept used an ActiveX object, its value was apparently seen by other browser makers, as Mozilla introduced support for their browsers back in 2002, with other browser makers following suit. (Though interestingly, Opera only gained support recently - perhaps this is related to the fact that they follow the W3C specifications closer than either Mozilla or IE)

Gmail’s been around for over two years, and other Ajax websites or web applications have also been in use for over a year. However, the W3C published their first working draft only back in April of this year, which is attempting to standardize a method that is already in wide use. Admittedly, it’s a valiant effort - currently, implementations differ across browsers (mostly IE in one corner, the rest-of-the-world in the other), so getting something down that everyone can agree upon is good.

Too little, too late?

However, it strikes me that it took them this long to develop even a draft. And, with many JavaScript frameworks out there that already abstract the XMLHttpRequest object in such a way that you don’t have to worry about incompatibilities, isn’t some of this work perhaps done in vain?

Thankfully, there’s been some action to counter this slow reaction time. As with most standards bodies, slowness to adapt is a key problem. In fact, it’s why the W3C was developed in the first place, (ironically, it seems), in order to address the shortcomings of the IETF at the time. However, this time, the group that’s taken the helm is a not a vendor-neutral group, but instead one comprised solely of the companies and people who make browsers - the WHATWG.

The WHATWG is not meant to be competition for the W3C; they aren’t meant to replace them. Instead, they hope that by fostering a good relationship between browser makers, good standards can be developed at a fast rate on par with development in the real world. These drafts will then be submitted to the W3C, thus taking a lot of the workload off from the W3C.

W3C-what?

The W3C, which one shouldn’t remember to commend for their previous efforts, still sometimes comes up with specifications that, while looking good on paper, just don’t seem like they’ll translate into something real and usable.

Take XHTML 2.0, for example. With a name like that, you’d expect it to be a successor to, and be backwards compatible, with the current version of XHTML. Not so. In favour of a stricter definition of a document, backwards compatibility will not be included. All the talk of making your HTML/XHTML documents validate in order to preserve backwards compatibility and to ensure forwards compatibility seems to have gone out the proverbial window. For those who were skeptical on the usefulness of web standards, XHTML 2.0 must have seemed like the straw man they were looking for - it really underlined the separation from reality that the W3C seemed to taken. (Even the current versions of XHTML have problems that need to be addressed in the context of delivery over the web)

Maybe it’s time

So perhaps what we needed was the WHATWG - something to keep the W3C in line with reality, and to allow the speedy standardization of things that are still in the process of developing. So far, they’ve produced a few specifications, which have had an impact on the W3C. Their continued interest in text/html as a viable MIME type is rare; too often, people get caught up in current trends, such as the love-affair that everyone seemed to be having with XML a while ago. While certain XML formats are good, they do have issues when there’s a chance the XML will be hand-coded and not checked for well-formedness errors. In this case, traditional HTML in the text/html MIME type is probably better.

In conclusion, hopefully the state of web standards will be better in a few years or so. The W3C has a lot of good to offer, especially when it comes to accessibility and so forth. Combined with the helping hand of the WHATWG, things should progress for the better.

In my spare time, I’ve been looking and collecting Ajax resources, but this list should hopefully accomplish a lot of that work for me.

Since the coining of the the term AJAX over a year ago hundreds if not thousands of websites, blogs and forums have been buzzing with posts on the subject. As I’ve found this can sometimes leave search engines bewildered as to where the current and relevant information really exists. So I thought I would put together this list of what I think are some of the most relevant AJAX sites are worldwide.

Do check it out if you’re at all interested in web development, it looks to be a gold mine of information.

Perhaps the best example is Gmail. While most of the buzz surrounding it during its launch was the then-unprecendented storage allowances, the service also implements AJAX to improve the quality of the application and make it seem more like a desktop application than a web service. For example, when you start typing in someone’s e-mail address in the “To:” field while composing a message, you’ll find that Gmail pops up a list of possible matches as you type, allowing you to quickly select the intended recipient - this is AJAX at work, and basically it allows your web browser to communicate with the web server to update and provide information to parts of the web page without having to reload the entire site, thus making it seem more like a regular program.

The power of AJAX was quickly apparent to many web developers and since then, many new and interesting applications based on its principles have been made. Indeed, WordPress, what I use to run this site, also nicely implements AJAX in its admin pages. It seems likely that AJAX will continue to permeate more and more websites.

With this proliferation should come caution. The potential for problems is high, not necessarily because of AJAX itself but because of the ways it can be implemented. First and foremost, AJAX should not be put into a website just for the sake of having AJAX there - sometimes simplier is better, and if it isn’t needed maybe it shouldn’t be there. Additionally, AJAX should probably not be required for the website to work - thankfully, major services like del.icio.us and GMail have followed this unwritten law; it’s not unlike the unwritten mantra for plain old Javascript and websites.

Secondly, security is an issue, as outlined in this article. In it, Stewart Twynham remarks that because AJAX is a new and developing technology, clear design patterns do not exist and thus this increasing the chance for poor coding that inherently leads to security and other problems. Additionally, the increased amount of scripts and code and the way they’re laid out can lead to complexity issues - thankfully, there is help available now. With the recent release of Yahoo! UI Library and the Google Web Toolkit, AJAX development can be greatly simplified - it should be noted there are many community-driven AJAX and general JavaScript frameworks and libraries also available that do the same thing, and sites dedicated to making AJAX coding more efficient exist. With the popularity of AJAX, such developments were inevitable; however, since AJAX is still relatively new and is still in the process of growing and being standardized by the W3C, a cautious approach is still needed here. (The slow response of the W3C to AJAX and other technologies is however, another topic.)

Lastly, user interface requirements must be considered - though AJAX is mainly used to improve interactivity and thus user experience, there are ways that it can be detrimental to user experience. With AJAX, there is increased potential for making a web application that doesn’t make its state known to the user, causing confusion and annoyance, and worse still, possible data loss. Your best bet here is to have someone experienced with UI design take a look at what AJAX is doing to the interface.

So in short, AJAX is a promising technology, and if you haven’t heard a lot about it already, you will be soon as it slowly becomes more and more prevalent on the Internet. Let’s hope web developers implementing it follow good coding practices.