The theory is that you would like to run the same tools as the attacker. The attacker will run a list of "probable passwords" based on what he knows or guesses of the psychology of the users. John the Ripper is a well-known password cracking software which includes lost of "usual passwords" and rules commonly employed by users to derive witty passwords.

Your advantage is that the server code has access to the password itself when the user registered. Contrary to the attacker who must run each guess through a potentially expensive hashing process (and it can be heavy if you crank the bcrypt iteration count to its full power), your code can work on the actual stuff and do some optimizations such as, as you suggest, normalization to lowercase.

However I think this is not a very good idea on a general basis. The attacker is not restricted to openly available software; he can adjust his list of potential passwords to the actual target (e.g. using more derivations around the names of the children of the specific user whose password is under the fire of the attacker). Even keeping up with the list of "common weak passwords" is likely to be a tiresome process. Moreover, the user himself will enter the game: since password restrictions are felt as an irksome hindrance by users, they will use all their creativity to find even wittier password generation rules which evade your tests.

Enforcing complex password exclusion rules on the server is somehow fighting the attacker on his battleground, and will bring the user to the feast; the user may unfortunately (and without guile) side with the attacker.

Therefore, I would recommend against such rules. What you need is the collaboration of the user, and you will have it by being transparent about the rules you employ; the user must be able to find a password which "passes your test" without entering a trial-and-error process. Nothing is more annoying than choosing ten successive passwords until one is finally accepted by a rigid server. You do not want to annoy the user, because an annoyed user will help attackers (he will not think about it like this, but that's the net effect). Explicit rules ("at least 8 characters, at least 1 digit") are much better for pedagogy.

And, of course, nothing beats proper education and training of users about the dangers of non-random passwords.

The theory is that you would like to run the same tools as the attacker. The attacker will run a list of "probable passwords" based on what he knows or guesses of the psychology of the users. John the Ripper is a well-known password cracking software which includes lots of "usual passwords" and rules commonly employed by users to derive witty passwords.

Your advantage is that the server code has access to the password itself when the user registered. Contrary to the attacker who must run each guess through a potentially expensive hashing process (and it can be heavy if you crank the bcrypt iteration count to its full power), your code can work on the actual stuff and do some optimizations such as, as you suggest, normalization to lowercase.

However I think this is not a very good idea on a general basis. The attacker is not restricted to openly available software; he can adjust his list of potential passwords to the actual target (e.g. using more derivations around the names of the children of the specific user whose password is under the fire of the attacker). Even keeping up with the list of "common weak passwords" is likely to be a tiresome process. Moreover, the user himself will enter the game: since password restrictions are felt as an irksome hindrance by users, they will use all their creativity to find even wittier password generation rules which evade your tests.

Enforcing complex password exclusion rules on the server is somehow fighting the attacker on his battleground, and will bring the user to the feast; the user may unfortunately (and unintentionally) help the attacker.

Therefore, I would recommend against such rules. What you need is the collaboration of the user, and you will have it by being transparent about the rules you employ; the user must be able to find a password which "passes your test" without entering a trial-and-error process. Nothing is more annoying than choosing ten successive passwords until one is finally accepted by a rigid server. You do not want to annoy the user, because an annoyed user will help attackers (he will not think about it like this, but that's the net effect). Explicit rules ("at least 8 characters, at least 1 digit") are much better for pedagogy.

And, of course, nothing beats proper education and training of users about the dangers of non-random passwords.