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

Once it’s in the Camera Roll you can set it as wallpaper.

This page will be updated as I find new ones to include.

The ⌘ key is also known as Command
The ⌥ key is also known as Alt or Option
The ⇥ key is also known as Tab

In OS X you can swap between applications in a similar way to Windows (Alt+Tab on Windows, ?+Tab on OS X) however there’s one important difference – Windows swaps between all open windows, but OS X only swaps between apps.  The problem is that in OS X you can switch to the right application but the window you want can be minimized.

To restore the window from the dock you need to:

1. Hold ?
2. Press Tab until the correct app is highlighted
3. Hold Alt
4. Release ?
5. Release Alt

It’s a bit tricky but you soon get the hang of it and it’s easier than picking up the mouse