The way this is typically done is that you don't need a password policy until you change it, and the administrator is immune to the policy (i.e. could create an "illegal" password.)
You need a "UserChangePassword" module that does something like this:
1. Prompt user for cleartext password. The Input box can be told to not echo input. You probably want the user to confirm the password by doing this a second time, so it is that you ask to "Enter new password" and then to "Verify new password."
2. Now that you have the cleartext password, you need to consider whether you will enforce complexity rules (like, uppercase, lowercase, digits, punctuation). If so, at this time you use the InStr function to scan each character and determine its category. In essence, your categories will be "UPPER" "LOWER" "DIGIT" "PUNCT" and "DISALLOWED" cases. The latter would include control characters and anything else that you don't want to deal with. I disallow spaces, tabs, anything that is non-printing, and a couple of characters that typically are handled as Windows or Access "special" characters. Either the password passes or fails complexity Since I am at a government site, my rules are to have a minimum of 2 each in the UPPER, LOWER, DIGIT, and PUNCT categories and a maximum of 0 in the DISALLOWED category.
3. Here, if the password meets complexity rules, you can check for minimum size. Do that next. Password minimum size is a pass/fail test.
4. If you want to do this and have a "dictionary" available, you can check for the user to have used a dictionary word for this. Look up Word to see if you can locate its dictionary file and see if there is a Word action or method that would let you compare the cleartext password vs. the dictionary. This is a pass/fail test.
5. If you want to check against password re-use, you need a password history table with username and password. I suggest that at this point you encrypt/hash the password so you can store <user,hashed-password,date-reset>. Password re-use is a pass/fail test. Either the hashed password is in the table or it is not.
6. Something that some sites require: A MINIMUM password age - to prevent the user from "churning" the password history table in an attempt to allow re-use of a "favorite" password. For this, you need to note the most recent password date AND TIME. Then get a DateDiff in units of seconds. For my site, it is required that a password stay as-is for 86400 seconds (= 1 day). This is a pass/fail test.
7. At this point, you can decide whether to change the password or not based on other rules that might apply. For instance, we have a site rule that says a user might be marked as "cannot change own password" (I.e. requires a supervisor to force the new password.)
So now, you've updated the password.
It is the login module that needs to accept a cleartext password, convert to encrypted format, and allows or disallows the login. But it is also here that you need a couple of other tests if you want to be a "big boy" type of password manager.
You know when the password was last updated. So if the password has an associated "maximum age" you can force a password update or disallow the connection if the user is marked as "supervisor must change password." You also need to consider that you should start counting password failures because typically, you do something like "If you get x failures in a row in y minutes, disable the account." Which means you need to track failures to have timing info on same, and you also need a "Supervisor must re-enable the account" flag to lock out further logins in that case.
One other thing: If you do this kind of anal-retentive checking, you need to consider that the message you give to the user must be limited in the information it returns. Like "Login failure" is all you say regardless of whether it was a bad username, a bad password, or a locked account, or the user's password has expired and needs reset.
Now, if you used domain-based logins and just captured your user's identity through the domain, this would be done for you automagically. However, if you MUST "roll your own" then these are the typical issues to consider.
