The Virginia Tech policy on password resets states that an administrative reset of a password should result in a temporary password that must be changed by the user before it can be used.
Currently, password changes are not forced after a password reset, which may result in users with very weak passwords, and passwords known to others.
Since this policy is currently not implemented, this document seeks to provide solutions to this problem.
The following solutions depend on knowing how password expiration will be implemented:
A password reset will set the password expiration date
When the password expiration date arrives the user's passwordState
attribute will be set to expired
ACLs will be written which do not allow authentication when passwordState
Whenever a user changes their password, the password expiration date will be cleared
Other processes may be implemented which set the password expiration date.
One Auth Allowed
When a password reset occurs, the user will be allowed one authentication in order to login to the portal and change their password.
When the user changes their password, the expiration date on the password is cleared.
If the user wastes their login without changing their password, the reset process must begin again.
This solution depends on the LDAPs making web service call backs to the Registry.
This functionality is planned for use with authentication statistics, but does not yet exist.
Reset Web Application
A special web application must be developed which can only be used by user's with expired passwords.
It authenticates against the Registry to avoid expiration problems and allows a user to change their password, thus removing the expiration.
When a password reset occurs, the user's password expiration date is set to some date in the future. (24 hours?)
The user has this length of time to perform a password change.
If a password change does not occur, the user's password state is set to expired, locking the account.
The new password reset tool is added to the DAT for 4Help which doesn't allow them to select any password they want.
Instead the tool generates a random password which conforms to the password rules.
Users can either keep the new password or change it, either way they have a strong password.
The old password reset tool would only be available for administrative purposes.
I think the scheduler makes the most sense, although the verbage in the policy will have to change. — firstname.lastname@example.org 2005/10/04 23:17
As you know, I'm for the scheduler as well. A distant second would be the One Auth Allowed solution. The scheduler is the best option because it does not require anything external to the system, and thus no hoops for users to jump through (such as other webapps). All operations start at the registry and replicate as usual.
Does this affect the mail system in any way? Should the password states be honored in the mail system? If not, we can send courtesy emails to users about password resets and impending password expirations. If so, uh…?
Another possible option, which admittedly sidesteps the problem completely, is to have 4Help generate strong passwords conforming to the password rules and set the user's password with this value. Setting a pseudo-random password would almost certainly have the desired side effect of having people reset their passwords. — email@example.com 2005/10/05 11:41
I'm adding the pseudo-random solution — firstname.lastname@example.org 2005/10/05 14:09
Scheduler looks like the most solid idea, but 24 hours? I'm gone over the weekend and my account is locked when i get back? On the other ideas, how is the user notified of what their new, pseudo-random password is? — email@example.com 2005/10/05 12:02
All resets require manual intervention with 4Help, they would tell the user they have 24 hours to do a change. — firstname.lastname@example.org 2005/10/05 14:09
In terms of mail authentication, I think we should have authentication blocked whenever it is blocked for the everything else. If someone knows my password, they can possibly see sensitive emails (SSN's, etc.), send email as me including abusive emails, etc. I view the mail account as just as extension to the user's pid account which unfortunately has to have its own authentication mechanism at this time. Having Active Directory with its own account and password is also an issue. If we block authentication for the mail server, we probably should also block it in Hokies, which would include Exchange, by setting the Hokies account disabled. The scheduler solution does allow a brief time for an email to be viewed by the user if we want to include sending one.
Having the temporary password be strong is certainly preferable in terms of keeping someone from guessing the password before the user can change it. We basically just have to trust that the 4Help people are honest. It seems like it would be good to combine the pseudo-random reset with the scheduler.
email@example.com 2005/10/06 14:08