NineChime forum

Proper security depends on a lot of things.  For all effective purposes, these two hashes are about the same quality.  SHA1 is obviously much tougher to crack than the stock crypt() method, but unlike the crypt method I use, the SHA1 hash you use is still vulnerable to rainbow attacks (IE, using identical password on two different web sites produces identical hashes).

Your password policy, how the hashes are handled, and how you handle brute force attacks makes a bigger difference.  Hashing is only really good for protecting peoples' passwords in the event of a database dump, via an SQL injection vulnerability.

To keep things simple, I'll cover the basics.

A strong password is one that has been salted, and then hashed multiple times.  For a small fan site, this is overkill and will likely be the strongest link in your security chain, but it's still the right way of doing it.  Salting the password means adding a known but secret postfix to the password before it is hashed, to help defeat the rainbow attacks I mentioned above.  Hashing it multiple times means that it will be computationally impractical to try to crack it.  So, a really strong hash (by SHA1 standards) would be something like:

define('HASH_SALT', 'fmpVu7hYDG'); // Choose your own gibberish here
$hash = myCrypt($_POST['password']);

function myCrypt($pass) {
   // TODO: check that pass isn't an array

   $pass .= HASH_SALT;

   for($x=0; $x<4; $x++) {
      $pass = sha1($pass);
   }

   return $pass;
}

More important is making sure that scripts can't just guess passwords.  People tend to have weak passwords that can easily be guessed, so here's a few tips for improving security:

- Use HTTPS when possible.  This helps keep hashes hidden when sending HTTP requests.
- Limit the number of login attempts to 1 every 2-3 seconds.
- Lock an account for 10-15 minutes if there are more than 10 login failures.
- Encourage people to use pass phrases rather than passwords.  The more words and the longer the password, the more secure it is (in theory).
- Don't force people to change their passwords regularly.  People will just end up using things that are even easier to remember and guess, like "pass1" -> "pass2" -> "pass3"...

Also, in the future, don't bother to escape the $_POST data before you hash it.  It's possible that the escape function may change in the future to include more sequences, and this may break passwords.  Of course, if you're already using it, it's too late to remove it.  Just keep in mind that you should only use known, consistent ways to salt a password before you hash it, and escape methods may change over time.

This is a consequence of using tables instead of divs.  A table will stretch to fit the content.  A div, on the other hand, will simply allow the content to overflow out of its container, resulting in the word going off screen.

I don't think there's a way to force word wrap to handle long words correctly, because long words are not supposed to be broken.  You can use the "overflow: scroll" CSS property to fix this, but that's probably an even worse solution than just letting the table stretch to the size it needs to be.  You can read more about the overflow property here: W3Schools: overflow