Despite being a fundamental aspect of security, authentication—which provides some assurance that a user or client computer is friendly and can be trusted— doesn't always get the attention it deserves. Without authentication, you can't properly enforce authorization and access control according to a user's identity.
Misconceptions about authentication abound. This article is the first of several in which I'll explain some core concepts about Windows authentication and help you learn how to use it effectively to provide secure access to the resources in your environment. Let's begin with a deceptively simple facet of managing authentication: password resets.
The Trouble with Passwords
Most Windows environments rely primarily on password-based, single-factor authentication. Single factor signifies that only one factor—the password—is required to successfully authenticate a user. In the case of passwords, this factor is something the user knows. Although using passwords as the factor is convenient and requires no special hardware or enrollment process, authentication based on something the user knows has significant weaknesses.
Forgetting a password is easy to do, and entering passwords over and over again becomes monotonous. Human nature being what it is, users tend to select weak passwords that are easy for them to remember—and easy for an attacker to guess.
Furthermore, users can forget their passwords, creating extra work for the Help desk by requiring a password reset. In larger organizations, password resets often create such a burden that many organizations implement a self-service password-reset solution. But password resets, whether provided by IT staff members or a self-service solution, open up numerous vulnerabilities.
The Human Touch
The danger of having IT staff reset passwords is that users or Help desk workers can be socially engineered. (Also, Help desk staff can turn rogue and misuse their authority to impersonate other users.) You need to train Help desk staff to authenticate password-reset requests carefully before carrying them out and to recognize social-engineering techniques.
Some Help desks carry out verification by comparing the caller's extension to the extension assigned to the user whom the caller claims to be. But in effect, that method grants access to applications, transactions, and information according to the caller's access to a particular cubicle. How does the Help desk know that the person on the other end of the line isn't simply someone who gained access to the office area and looked for an unoccupied cubicle?
Other organizations require a user's manager to submit a digitally signed email requesting that the user's password be reset. The Help desk must then contact the user and tell him or her the new password.
Another option is to have the Help disk leave a reset password on the user's voicemail. This method relies on the user's voicemail PIN to protect the password. When combined with a signed managerial request, this method can be a reasonably strong one for authenticating password resets—depending on the security of the voicemail system.
Some organizations give the Help desk access to the last four digits of each employee's social security number. The first time I heard of this method I scoffed, thinking you might as well give everyone a four-digit password and forget about requiring longer, hard-to-guess passwords. This is a classic method used against call centers of all types: An attacker repeatedly calls in, reaching a different representative each time, making a different guess with each representative in an attempt to defeat the controls.
Train your staff, especially if your company has a large Help desk, to maintain a database of user calls, to record each call requesting a password reset or other sensitive information, and to consult the database for calls associated with each user before complying with any request.
To mitigate the risk of rogue IT staff members misusing their password-reset authority, you must have a strong audit trail of password resets in place. You must perform spot checks to verify that password resets in that trail correspond to a support call or other request record. Make sure your support staff knows that their work is being audited. These steps put a deterrent control in place to limit the risk of inappropriate password resets.
Automatic Authentication
Using an automated password-reset solution effectively eliminates a lot of work for your Help desk and removes the risks associated with social engineering or dishonest Help desk staff. But a self-service solution must still authenticate requests.
The best systems I've seen require a user's manager or other trusted account to authenticate to the application (usually an intranet Web application). The user then enters the last four digits of his or her social security number.
Such solutions work as long as both the user and manager are physically present at one location. Otherwise, the method becomes problematic because the user must divulge part of his or her social security number to the manager so that the manager can change the user's password.
Other self-service solutions use voice recognition and social security number verification to let users reset forgotten passwords with a phone call. Provided that the voice-recognition software is good enough and that the solution dynamically chooses sample text for the user to repeat, such solutions are a good choice.
Some password-reset solutions verify user identity by using a series of questions and answers based on personal information, such as the user's mother's maiden name or favorite pet. Be careful selecting which questions the solution uses: Some answers can be guessed easily, and these types of solutions can create yet another enrollment task that you must complete for new users.
Self-service solutions eliminate most of the risk associated with delivering new passwords to users because the user, after being authenticated, specifies the new password to the password-reset application. Still, self-service applications need to be designed, coded, and installed with security in mind to prevent the application from being hacked.
A Necessary Evil
Until we replace passwords with two-factor biometric or token-based authentication, password-based authentication is a necessary evil for both users and IT staff. This type of authentication often requires password resets, a vulnerable process with multiple attack vectors.
As long as your Windows environment relies on password authentication, you must pay careful attention to the password-reset process, making sure that reasonable controls exist at each step.
Randy Franklin Smith (rsmith@ ultimatewindowssecurity.com) is a contributing editor for Windows IT Pro, an information security consultant, and CEO of Monterey Technology Group. He teaches Monterey Technology Group's Ultimate Windows Security course series and is an SSCP, a CISA, and a Security MVP.
