There is a long discussion on whether it's the responsibility of the user or the system administrator to deal with the strength of the password. Obviously, the password is a very private thing, but evidently, weak passwords jeopardize the entire organization and other user's data as well.
What are the ways of ensuring the user will pick a strong password and/or pick a password that is not one of the first tested passwords in a brute-force attack?
There are a few ways I can think of.
Require certain character combinations
This is a commonly used technique. Require users to input a certain combination of characters like a mix of capitalized words, non-capitalized words, numbers and symbols. Enforce a minimum password length. Do not be overly restrictive though, as it might force users to mix combinations in an insecure manner.
Password1234 is no more secure than password.
This technique could also restrict strong passphrases. See: XKCD #936: Short complex password, or long dictionary passphrase?
Deny common passwords using a blacklist
Maintain a blacklist of commonly cracked passwords and do not allow the users to register using them. This could prove to be a sizable amount of work to maintain.
Education, threats and tools.
The first mitigation for security issues is to enlist users. You cannot obtain good security without their awareness anyway, so you might just as well ask for their help. Publish guidelines on how a password should be chosen.
To strengthen the previous point, pressure them a bit (just a tiny bit). Speak the fateful word: "responsible". Humans being humans, some will need the extra incentive; notably, taking care to explicitly spell out whose fault attacks will be, will emphasize the seriousness of the issue. People won't believe in the importance of the security issues if you, as server maintainer, do not do your homework. These small, thinly veiled threats will push the users into the slightly uncomfortable zone where they are alert. Don't overdo it ! You want users who comply, not users who fight your system.
At that point, help the users. The basic fact of password generation is that humans are no good at randomness. But randomness is what is needed for a password. Since this is a webapp, you have a trusted Web server -- "trusted" in the sense that the password is to ensure the safety of that server, so the server itself cannot be an enemy (it would make no sense). Thus, use that server: include a password generator. Something which will produce good passwords, accessible with one click.
The two facets of password generation are that the password must not be guessable, but it must be memorized nonetheless. By giving rules for password generation, you assume that the mnemonics by which the user will remember the password will match exactly the process by which the password was created. This is an artificial restriction. Consider the famous XKCD password generator: the generator is not about choosing four words which "make sense" together; instead, it is about selecting four words at random and then, only then, find a "meaning" for it (such as the ungulate mammal pondering electricity storage devices). This highlights how strong passwords are produced: use randomness, then train the brain to cope with the result.
A password generation scheme I am rather fond of goes thus: generate two letters, then two digits, then two letters, then two digits. To please inflexible application interfaces, make the first two letters lowercase, and the other two uppercase. The entropy of this generation process is 104*264, i.e. a bit above 232. 32 bits of entropy are not bad: it will take an average of more than two billion tries to break a password of that kind. This is enough for online security (it would take much too long for your server to "try out" that many passwords). On the other hand, I find that this random passwords are easy to remember. Try it ! You already remember phone numbers, which are numeric-only; the letters are great "anchors" for the mind, and make the memorization only easier. Here are five passwords of that kind, freshly generated (I did not choose them):
sf57HD04
sd82PI16
ny21BF75
xv53AQ36
jz91EQ92
For each of them, I wage that you are already finding a simple way to "rebuild" it in your brain, as if you had created it in a witty way. But since they have been generated with real randomness, their entropy is intact.
I'd also add that weak passwords can be significantly mitigated if there are good restrictions on login attempts. It isn't going to protect you if your hash file is lost and undetected, but at that point it is more of an administrator issue. The biggest concern for higher security stuff would be that passwords could be reused from other sites which could be compromised. Making a username that is not directly matchable to a user is a decent way around this. Even if I know that Bob Worker uses BobW0rker12345 for his facebook password, if I don't know Bob Worker's login credentials, then having access to his Facebook password doesn't help me.
Password complexity requirements can also help make sure that it can't easily be guessed, but also come with a variety of stupid user trick caveats such as people writing passwords down or becoming directly frustrated with your system and directly trying to fight against your system because it is making their life difficult, so you should always weight the risk vs reward for password complexity requirements. Sometimes it is truly necessary and if so, then it goes to the third and most critical point of user education.
Your users have to understand why the level of security is necessary and be willing participants. Ultimately, your users collectively are far more creative than you and they WILL do things you didn't expect that compromise security unless they understand the importance and are invested in it.
The answer should stronlgy depend on the purpose of the password.
Is something like a forum? Then don't annoy users by forcing them to replace the o in their default password by a 0. That's as far as they will go before simply abandoning your site. Feel free to notify them that their password sucks and that you won't take any responsibility, but don't force them to use the only complex password they can remember - that to their PayPal account...
Is it something like a shop? Then warn users about the weakness of their password and maybe have them confirm twice, including a "I am aware that my password is more likely to be cracked than others and I won't come to you crying about it when that happens" statement. But don't force them to use a password they can't remember - I'd argue a password manager should be standard, but it isn't, and your users shouldn't consider the password reset function as the default way to log in. Consider offering Two-factor authentication or OpenID instead.
Is it actually the web interface to launching a nuclear weapon or triggering the ISS life support systems? In that case, using a mere password authentication is a serious flaw in itself, though not as bad as actually connecting these things to the internet.
Entropy calculation.
A dictionary word, proper name or other member of the modern English language has, on average, about 1.5 bits of entropy per letter. To this, you can add a bit for each capital letter, a bit for each "leet" substitution (0 for o, 1 for i, 2 for q, 3 for e, 4 or @ for a, etc), 3 bits for each numeral digit in a prefix or suffix that is not in sequential order, and 4 bits for each punctuation mark not used as a substitution.
To calculate entropy automatically based on an entered password, I'd strip all leading and trailing numbers/symbols, split on capital letters and run what's left through a spell-checker to get the actual word(s).
Take the sum of all bits of entropy, and raise 2 to that power. That is how many brute-force guesses it would take to try all possibilities using a dictionary-based cracker. How fast it could happen depends on how fast your front door can process login attempts; I recommend password verification based on a slow hash (bcrypt) server-side coupled with a maximum number of login attempts, on top of whatever mechanism you use to secure password transmission from client to server.
Anyway, once you have a score and know what it means in terms of the length of an attack (honestly, if you see even 3 hours' worth of repetitive failed login attempts, there should be alarm bells going off), you can set thresholds for "weak", "normal", "strong" etc, and don't accept a "weak" password. Understand that due to Moore's law, today's strong password is tomorrow's weak password, and what takes a GPU-based cracker years could take a botnet or an intelligence agency days.
Password protection in itself is inherently insecure
The question cannot be easily answered without additional context. How strong a password needs to be depends on the value of the resource it is protecting. Therefore, to what extent an application should do anything about the strength of a password depends on what it is protecting (although, there is an issue of people who use the same password on multiple sites - see next point).
User education and awareness is critical. Lack of eduction and awareness will create resentment amongst your users if you force them to use passwords you consider very strong and they consider difficult to create or remember. Likewise, a mismatch between enforced strength and perceived value of what is being protected will cause resentment.
Consider the threat and how it may be realized. Brute force attacks rarely occur via an application interface. More often than not, they are applied to a bunch of passwords which have been stolen from the applicaiton's backend repository. There is no point in forcing users to enter strong passwords if they way you store and manage those passwords mean that someone is able to obtain them. Given time, enough CPU and memory and poor encryption algorithms, password strength becomes irrelevant.
All that aside, I think it is reasonable to reduce your exposure by enforcing strong passwords. I wouldn't go overboard. Enforce a minimum password length, mixture of upper/lowercase and inclusion of number and punctuation characters, but accept users will find/do things which will still compromise your attempts. Recognize that passwords are just inherently insecure when used as the sole method of authenticaiton and weight that up against the value of what is being protected. If the risk is still too high, then consider additional mechanisms, such as two factor authenticaiton.
This stuff is not measured in absolutes. There is no one size fits all solutions and password strength is not the only piece of the puzzle you need to consider. Look at how you store and manage passwords, consider where an attack is likely to come from, how you will be alerted to such an attack, how to get your users to adopt good practice, how to balance value and inconvenience of any security measure etc. and remember that this is not a do and forget process. This is something which needs to be reviewed and updated on a regular basis as technology, techniques and behaviour changes.
A better question may be: Why does my web-application requires passwords in the first place?
I don't have any passwords for any of my StackExchange accounts!
Depending on the application, tying it with another authentication service, or generating a pseudo-random password by default, might be the best approach.
If you generate a pseudo-random password, you might want it to be random enough, yet easy to remember.
There are a number of tools that generate passwords with consonants interchanged with vowels, potentially interchanged with a couple of numbers; such passwords are inherently strong for web-applications (since you can't brute-force a web-application undetected), yet they're easy-enough to remember, since they don't actually look totally random, but resemble some strange word or name.
An example of a good tool that generates such easy-to-remember, readable and pronounceable passwords is a console tool called pwgen.
http://sourceforge.net/projects/pwgen/
http://screenshots.debian.net/package/pwgen
