Ah, you caught me before I finished editing (my chronic bad habit of publishing before proof-reading) ninja’d again.
Even though it is true that as long as you’re hashing the sky’s the limit, realistically I doubt many users would want a humongously long password nor expect to be able to have one.
IMHO 40 characters is probably longer than most would use. If anything, limiting the shortness and requiring a “mix” of alpha lc/UC and non-alpha makes more sense.
Yes, considering how many have used “password” or their pet’s name etc. because anything else was too difficult to remember, I imagine some might have trouble with the requirements. But it is a really good idea and helps prevent “brute force” attacks.
Don’t make the password complexity requirements too complex, otherwise folks won’t remember them.
The shorter the password is, the more vulnerable a password is to brute-force, regardless of how “complex” it is.
I tend to just require a minimum number of characters, letters, and at least one number, and only suggest symbols and uppercase letters.
I also tend to use stronger hashing algorithms which results in more characters. Why? Well, it costs next to nothing in terms of storage space and processing power, and since it’s ultimately more secure than lesser hashing algorithms, why not?
Great discussion on passwords and … well, the OsamabamaCare website was said to be insecure but the report here is so ridiculous as to be laughable. 'Sure the Blues and Greens know what they’re doing (whoops, the “brownie,” too - sorry, Wyatt, I didn’t mean to exclude you!).
I believe that MD5 is supposed to have been cracked. Stick with the SHA1 (or better) hashing!
Let’s not forget that Hashing algorithms is only part of the solution.
As @DoubleDee; astutely pointed out, collisions (which result in duplicate entries in the database) are a great asset to a would-be hacker.
That is why it is important to use a unique salt before hashing.
There are two ways (that I know) to approach this. You either include the username as the salt. This is the most common because it is the simplest.
The other is to generate a random string to append (or prepend) to the password before hashing. In this case you need to store that unique value in the database also.