test password strength against an extensible list of passwords that defaults to really common ones

In #830970: test password strength by comparing the password to the username we are checking for username = password.

We should also check for password in a set of commonly used values. The module can provide a couple hundred common passwords to use (we've found them to be useful) and then allow people to extend the list to more passwords.

My first idea was to just use a database table with the word and a hash. Unfortunately, then if someone finds sql injection that allows them to select data (but not inject - this is the most common case of sql injection in Drupal) they can use the rainbow table "feature" to identify the password for the account. Ooops.

My next idea was to create a table of hashes with the original word. This could still be useful for identifying accounts with weak passwords which therefore would be useful to focus a brute force attack.

My next idea was to make this feature work by using passwords in an array and using a giant in ('123456', '1234567', '12345678', '...') so that the only way for an attacker to leverage this is if there is a code execution vulnerability and if there's one of those...your site is already screwed. I imaging this would be slow.

Another idea is to reduce the lifespan of the rainbow table so it mostly has zero entries but when a security check is executed it loads the data into the table, then uses it, then truncates it. This just reduces the window and someone could still leverage it for an attack.

Another idea is to use database prefixing and provide documentation for creating a separate mysql user. security_review.module could use a mysql account that has access to this table using the database prefixing system and don't grant permissions on this table in general. So, sites that really care about security could hide with the mysql account.

Another idea is to use a random table name for the query or a user selected table name, but this is really security through obscurity and maybe it's worthwhile in combination with all the other ideas...maybe not.

Another idea is that this feature could be limited somehow so we say "only run this on backups of the live site that are not accessible to the outside world."

So, which of those ideas are worth pursuing and which aren't?