Password Complexity

[DavidRieman]

In addition to fixing the currently-broken password change command (#43), we may as well make sure that just using "password" with no arguments and/or "help password" has information about password complexity requirements, if we have any in place.

@duaneking adds:

System can have security requirements/eventing on password attempts etc.
Server should have a set of password requirements banned passwords, rotation, etc?

Modern systems generally have more password complexity requirements than the MUDs of old. We should probably support these modern expectations out-of-the-box, while also making it easy to replace the password requirements without having to modify the Core code. There are a couple ways that come to mind we could accomplish this, that work with the systems we are building now:

• Password set/change attempts could raise a wide PasswordChangeRequest event. A core event listener would listen to all such events, and based on a basic app.config setting, validate the new PW against a set of default complexity rules. If the listener code didn't like it, it could deny the request with a message like "Passwords must include at least one numeric character and one symbolic character" or "Passwords must not be in the banned list of common passwords", etc. This would allow an admin to stack another validator by just having their non-code class register to the events. PW change requests would have to pass all validators in order to proceed. One downside is this approach might be weird to apply to setting the initial PW, where the player isn't even logged in yet - the eventing system may currently assume we need an actor Thing involved spawning the event. But it might just work as-is (with perhaps a null actor). Another downside is this wouldn't work well with a "help password" response, as accumulating the requirements of each listener wouldn't be straight-forward.
• Alternately, we could lean on MEF composition of behavior, like we do for Character Creation state machine and the like. One could plug in a new password validation module with a higher Priority than the Core one, to replace routing of password validations through their new class instead of the Core one. The required API could include a method to gather what the response of a command like "help password" should actually print to the uesr. This approach might be easier to hook up to the pre-login password setting code too, as it wouldn't require an actor Thing. One possible downside is it might be harder to design architecturally to support multiple validators that all get a chance at it. Or, perhaps the Core validator is always involved but could be configured off via the app.config, and all MEF composed validators get a chance, and we accumulate their "help password" requirement outputs together.

For example, suppose we didn't support a Password Rotation system out of the box (maybe because we weren't comfortable security-wise with also storing the history of salted hashed passwords for the users). An admin who wanted to add the rotation system would add a new class (or drop one in as shared from another MUD admin) into their game-specific project. Regardless of how (above), it would keep track of salted hashed PWs for each User with its own storage area, that it could read and compare to reject a PW change request with a message like "Your password cannot be one you have already used in the past" or whatnot. Having a forced rotation after X days would involve another API to ask the modules if a PW change is required, I guess. Which might be another point in favor of the MEF approach.

Or, maybe this is all overkill, and we should just have some basic options out of the box (configuring which options you want to enforce for minimum PW complexity via app.config), and require Core modifications if you want to change or improve on that (like adding forced rotations).

Thoughts or other options?