Better References

• http://www.w3.org/community/webed/wiki/HTML/Elements
• http://reference.sitepoint.com/
• https://developer.mozilla.org/en-US/docs

Good Tutorials

• http://www.htmldog.com/
• http://code.google.com/edu/submissions/html-css-javascript/
• http://www.html-5-tutorial.com/

Quick Solution

Use the -H option to specify the host name for the web site e.g.

define service{
	use                     generic-service
	host_name               andymadge.com
	service_description     HTTP
	check_command           check_http!-H www.andymadge.com
}

Explanation

The default definition for the check_http command uses the -I option for the address:

# 'check_http' command definition
define command{
	command_name	check_http
	command_line	$USER1$/check_http -I $HOSTADDRESS$ $ARG1$
}

According to the help (check_http --help) this option is used to specify the IP address or DNS name of the server to be checked.  If you specify a DNS name then Nagios does a lookup to convert it to the corresponding IP address.  In other words, the -I option will always send the request to an IP address rather than a host name.

Since a single IP address can be home to many web sites, an IP address is often not enough to identify a particular website.  In this situation, web sites are identified by the host header part of the HTTP request.

So, the default check_http command contacts the correct web server, however the lack of host header in the request means the server doesn’t know which actual web site to direct it to, therefore it responds with the 403 error.

To resolve this we need to use the -H option which specifies the hostname for the web site.  We could change the default command definition to use -H instead of -I however there are good reasons not to do this (see below)

The best solution is to specify the -H option in the service definition:

define service{
	use                     generic-service
	host_name               andymadge.com
	service_description     HTTP
	check_command           check_http!-H www.andymadge.com
}

Since the -I option is already specified in the command definition, we end up with the expanded check command:
check_http -I 72.52.225.30 -H www.andymadge.com

This means the request is sent to IP address 72.52.225.30 but the request header also includes host: www.andymadge.com

In this case, the web server directs the request to the correct website, and responds with a HTTP OK 200  response.

Why not change the default?

The advantage to leaving the default is that it allows you to do http checks without relying on DNS.

In the example above, DNS is not used at all, therefore Nagios is still able to monitor the website even if our DNS is down.

The problem is generally caused by someone editing the file with a text editor which doesn’t understand and maintain the different newline types. You then end up with a file containing a mix of different line endings.

Mixed line endings can have all sorts of unexpected consequences in your applications. Also, editing is really annoying since you have to do a lot more scrolling.

The common newline types are:

There’s more info in Wikipedia.

Removing the Additional Lines

The solution is to to use search and replace to get rid of the extra lines, and then convert all the line ending in the file to the same type.

First you need a text editor that can display the different types and also search for each of them separately. I recommend Notepad2 since it’s very good and also free.

If you open the file in Notepad2 then go to View –> “Show Line Endings” you’ll see the line endings:

Now that you know which line endings are in the file, you can bring up the Replace dialog:

To search for the line endings, you need to tick “Transform backslahes”

Then search for the corresponding line end type:

In this example I’m going to search for all the CR+LF and replace them with nothing. Hit “Replace All” and your file is magically back to normal.

The only thing left to do is convert all the line endings to the correct type. Go to File –> “Line Endings” and chose whichever type you need (do this even if it’s already selected)

You have now got a file with consistent line endings and no extraneous blank lines:

Alternative Method

An alternative method is to convert the newlines first and then swap all the double newlines for singles.

After converting the line endings you get:

Next do the following Replace:

Now you should have the same result as above.

Caveat

Before I continue, I just want to make an important point:

The single best piece of advice I can give when building your own authentication system is…

• Don’t do it.

I don’t mean don’t use authentication, what I mean is that cryptographic techniques are complicated.  Actually they’re extremely complicated.  If you don’t have years of experience as a cryptographer, you’re going to make mistakes that will leave security holes.  Guaranteed.

The alternative is to use a well respected authentication framework such as:

• PHPass
• Zend_Auth (requires Zend Framework)
• CodeIgniter Authentication Libraries (require CodeIgniter)

Frameworks such as this are developed by people who really do know what they are doing, and any security holes are generally quickly discovered and plugged.

I’m certainly no cryptographer, and this article is based on my current understanding.

That said, assuming you’re going ahead anyway, let’s get back to the article…

Attacks

Lets look at the type of attacks we want to protect against.

Dictionary

This involves having a list of common passwords and trying every one in turn.  Most dictionaries would contain millions of possibilities starting with obvious stuff like “password”, “123456″ and more obscure ones such as “pa$$wOrD” (wikipedia entry)

Brute Force

This involves trying every possible password and in theory will always work against any system.  The problem is that it takes a LONG time to do.  As computing speed improves, obviously the time taken reduces.  Since you can’t make brute force attacks impossible, what you want to achieve is to make them take an infeasibly long time – like years. (wikipedia entry)

Rainbow Tables

This is a way of attacking hashed passwords.  The idea is that instead of calculating the hash of each password you want to try, you use a list of pre-calculated hashes, thus saving computation time. (wikipedia entry)

Bearing those in mind, let’s look at the different ways you could store the password in your database:

Plain Text

This is a massively bad idea.  If someone gets hold of your database, they know everybody’s password.

NEVER EVER STORE PASSWORDS AS PLAIN TEXT.  ANYWHERE.  EVER.

One argument against this is “The spec requires that the password be stored in case someone forgets it.”  If that’s the case, then you should use reversible encryption and DON’T STORE THE ENCRYPTION KEY IN THE DATABASE.

Hashed Passwords

A hash is a one-way algorithm that is commonly used in cryptography.  The idea is that there is no way to work backward to find out the password from the hash value.  There are many different hash algorithms, each with their own strengths and weaknesses. (list of hash algorithms supported by PHP)

The most commonly used hash functions are MD5 and SHA1:

$password_hash = MD5( $password );

Lots of people will tell you that MD5 is sufficient for most uses, others will say that SHA1 is more secure so you should use that instead.

While these are two of the least-secure hashing algorithms, they are still secure enough for any normal website (i.e. not a bank etc.)

Other more secure hash algorithms are SHA256 or Whirlpool, but these have the disadvantage of taking longer to calculate.

So at this point, we’re recommending:

$password_hash = SHA1( $password );

Vulnerabilities

Hashed passwords will provide complete protection against dictionary attacks.  They also protect effectively against brute force attacks since the operation would take an infeasibly long time, however they are still vulnerable to rainbow table attacks.

Salting

Salting is a technique used to protect hashes against rainbow table attacks.  The idea is that an additional string – known as ‘salt’ – is introduced into the hash value:

$salt = "abcd";
$password_hash = SHA1( $salt . $password );

So, if a rainbow table attack is successful, the attacker now still doesn’t know the password, they know $salt.$password.  In this trivial example, the attacker would soon work out what the salt was – especially if they break another account – and then they would know the password.

Let’s improve the salt…

$salt = "ZvmLcZMXw3WIA78uudt9SFysSGocIF";
$password_hash = SHA1( $salt . $password );

Here we are using a random static string as the salt, which is definitely an improvement, but since the salt is static (i.e. the same for every user) then they still only need to work it out once.  After that, every user’s account it vulnerable to the same attack.

Note that we could also hash the salt as follows:

$salt = SHA1( "ZvmLcZMXw3WIA78uudt9SFysSGocIF" );

However, all this does is increase the computation time without significantly increasing the security.  The attacker only needs to find the value of $salt – it’s completely irrelevant how it’s calculated.

We need to make the salt different for each user.  One way is to use something that will be different for each user.  The most obvious thing is the username (or maybe email):

$password_hash = SHA1( $username . $password );

This means that if two people have the same password, they will still have different password hashes.  If an attacker is successful with a rainbow table attack for one account, they know nothing about any of the other accounts on the system.

Better still, lets use a different randomly generated string as the salt for each user.  NOTE: In this case we’re going to need to store the salt alongside the user in the database otherwise we have no way of checking it.

$salt = random_string();
$password_hash = SHA1( $salt . $password );

random_string is a function defined elsewhere in your code.  There are good examples here and here.

Finally, let’s combine some of the above into our best-yet version:

$salt = random_string();
$password_hash = SHA1( $salt . MD5($email) . $password );

I know I said above that there’s no point in hashing twice, but in this case it does have an effect – we don’t want the salting algorithm to be obvious and now password hash doesn’t contain anything that is recognizable as a word or email address.

It is important thing is that an attacker doesn’t know exactly how you have introduced the salt.  As a result you need to be careful with Open Source software, since the salting algorithm will be plainly visible in the source code – although this is mitigated if the salt contains a random string.

There are many different approaches to salting – this is just one fairly simple version.  For anything that requires a higher level of security, you’ll need to look at additional techniques.

As I mentioned above, I’m no security expert and I may have missed something.  If you think so, please let me know in the comment.

Also…

This hasn’t been the focus of the article but it’s relevant – whenever someone creates an account, changes their password or logs in, you’re going to be sending their password over the internet.  Unless you’re using HTTPS/SSL, then the password will be sent IN THE CLEAR i.e. as plain text.

Anyone who is listening in with a packet sniffer will be able to see the password so all of your back-end security goes out the window.

You may think “OK, so I’ll hash the password at the client using JavaScript before I send it.”   This actually doesn’t help at all – the attacker doesn’t know the password, but he does know the hash, so he can use a replay attack which in most cases is good enough for their needs.

You can improve the security by using Challenge-Response but the best alternative is to use SSL.

On investigation it seems that the two problems were unrelated, but here are the solutions to both of them…

Firefox 3.5

It seems there’s a bug in the Google Toolbar which can stop tooltips from working (you just get a small square instead). The fix is to uninstall Google Toolbar, then re-install it.

Internet Explorer 8

Bizarrely, this isn’t a bug.  It’s a rare occasion when IE does the right thing according to the W3C spec.  Basically, the HTML “alt” attribute has long been used to display tooltips over images, where in fact, it’s only supposed to be shown if the image doesn’t load.  The correct attribute for displaying tooltips is actually the “title” attribute.  Internet Explorer 8 has changed so that it works correctly according to the HTML spec.

What this means is that if a web page has only alt tags then in IE8 normal mode, you won’t see any tooltips.  If however the page is in IE8 compatibility mode, you will see the tooltips.

http://live.sysinternals.com/<tool>.exe

e.g.

http://live.sysinternals.com/procexp.exe

This works better in Internet Explorer than Firefox, since you can run the tool without saving it first.

Searches for a text string in a file or files.

FIND [/V] [/C] [/N] [/I] [/OFF[LINE]] "string" [[drive:][path]filename[ ...]]

/V         Displays all lines NOT containing the specified string.
/C         Displays only the count of lines containing the string.
/N         Displays line numbers with the displayed lines.
/I         Ignores the case of characters when searching for the string.
/OFF[LINE] Do not skip files with offline attribute set.
"string"   Specifies the text string to find.
[drive:][path]filename
Specifies a file or files to search.

If a path is not specified, FIND searches the text typed at the prompt
or piped from another command.

this can be useful with the netstat command:

netstat -ano | find /i ":80"

or when viewing the DNS cache:

ipconfig /displaydns | find /i "google"

Although that isn’t ideal since the output of ipconfig isn’t really formatted to play nicely with the find command.

Reference: http://nzpcmad.blogspot.com/2007/07/dos-grep-equivalent-find-command.html

If you make changes to DNS and want to test the results straight away, you need to clear the cache with:

ipconfig /flushdns

You can view the current cache with:

ipconfig /displaydns

or

ipconfig /displaydns | more

to see a screen at a time

Some suggestions from around the web:

1. It is probably caused by memory leaks in 3rd party apps.  You can close any app by holding Home button for 6 seconds.
2. iPhone 3G was released with firmware 5a345 but iTunes 7.7 contains firmware 5a347.  Do a restore from iTunes to get the newer version. Make sure you have synced and backed up before doing this, since you are completely wiping the iPhone.  Lots of people are saying that helps.
3. Rebooting the phone – hold power button for several seconds, it will ask you to slide to turn off.  Hold power button to turn it back on.  This is the same as rebooting any computer – you’re cleaning up the memory.

Battery Life

To extend the battry life, switch off WiFi, 3G and Bluetooth when you’re no using them. Hopefully someone will soon write a utility to do this easily and quickly from one place. I may even give it a go myself…

The screen will flash and image will be saved to Camera Roll