Security is only as good as the weakest link in a chain of systems and processes. Password security can be weakened by ineffective password reset processes. Password resets are only as good as the data used to authenticate users who forgot their password, and the process that was used to collect that data. For security to be effective, every link in the chain must be strong.
In most organizations, users who forget their password, or trigger an intruder lockout, are required to call the help desk for assistance. The help desk then resets the caller's password, or clears the lockout.
If the process used to authenticate the caller, or deliver a new password to the caller, is weak, then an intruder could attack this process, rather than a password, to compromise a legitimate user's accounts, and achieve a security breach.
Some help desks do not authenticate their callers at all. This is the best possible target for an intruder -- simply call the help desk, claim to be the intended victim of the attack, get a password reset, and start using the victim's accounts.
Other help desks use the last few digits of the caller's social security number or mother's maiden name to authenticate the caller. This is better, but social security numbers are readily available from credit bureaus and other sources, and mother's maiden names can also be readily extracted from an unsuspecting user. Help desks using these simple measures are still vulnerable to abuse.
Another technique to authenticate a caller to the help desk is to have the help desk call the user back at his desk number, or call the user's manager, and deliver a new password this way. This method essentially assumes that (1) the user must be at his desk and (2) no other person could possibly occupy that desk. These assumptions are weak, especially early in the morning, over lunch and in the evening. Physical security at most organizations is weak -- intruders could masquerade as visitors, vendors, or even the cleaning staff, or may simply be insiders. So again, the call-back method can be readily compromised.
A final technique is to reset passwords for any caller, but deposit the new password in the caller's voice mail box. This method is better, but it has two vulnerabilities: First, mail boxes are only protected with a short, unchanging, numeric PIN, normally without an intruder lockout alert on successive authentication failures. Should the security of passwords be reduced to be equivalent to a short, static, numeric PIN? Secondly, an intruder who simply wishes to cause a denial of service can make repeated calls to the help desk, masquerading as various users, and cause lots of passwords to be changed. This is a denial of service attack.
To secure the password reset process, regardless of whether it is assisted or self-service, users should be asked to answer multiple personal questions. Personal questions normally have constant answers -- i.e., the answer stays the same over time, and may be vulnerable to "social engineering" attacks. To mitigate this risk, multiple questions should be used, substituting quantity where quality may be impossible.
An intruder who must answer multiple personal questions may nonetheless defeat the authentication system, by doing sufficient research in advance. The intruder's job is easier if the set of possible questions is known in advance. For example, if every user is authenticated by some subset of 5 possible questions, such as SSN or mother's maiden name, then the intruder needs to research answers to five questions before attacking a legitimate user's account.
Pre-defined questions do have the advantage of being a known quantity. A security officer can select questions, such as favorite restaurant, name of first dog, etc, to which there are at least hundreds of possible answers. Combining many such questions obviously improves security.
Pre-defined questions can and should be supplemented by user-defined questions and answers. This makes the authentication process less predictable, and so less vulnerable to pre-meditated attack. If both types of questions are used, an intruder might have to defeat a system such as the following:
As mentioned above, one of the most effective ways to authenticate users who forget their own password is to ask them to answer multiple personal questions. Often, this information is not readily available, so must be collected from the users in an enrollment process. If the process used to collect this data from users is itself not secure, then the data cannot be relied upon to authenticate users, and consequently password reset processes will be insecure. In other words, an insecure method to authenticate users when enrolling Q&A data will compromise the security of passwords.
One process to enroll Q&A data from users is to simply ask them to e-mail this information to some central location, and process that data either manually or using some automation. This is insecure since e-mail can be easily spoofed -- an e-mail that appears to originate with user A might actually have been sent by intruder B.
Another process is to send users short, numeric PINs, and ask users to sign into a web form, either initially or at some future data (e.g., when they next forget their password), and use that PIN as an alternative form of authentication to their forgotten password. This is bad for two reasons: (1) password security should not be reduced to that of short, static, numeric PINs and (2) users may forget their PIN more easily than their password, thus totally invalidating the system.
In other words, e-mail from users and PINs are insecure methods with which to collect personal authentication data.
A simple alternative to the above is simply to require that users type their current password to some trusted system -- such as an LDAP directory, a Windows domain, or a mainframe, before being allowed to fill in their Q&A profile. Users know their own passwords (most of the time), and will be able to do this. Nothing secret is sent in either physical or electronic mail (passwords, PINs, personal data). E-mail can still be used as a mechanism asking users to register, but nothing sensitive is ever transmitted.