With users having so many passwords – both personally and professionally – and with the ability to have operating systems and browsers remember password on the user’s behalf, it’s understandable that they may find themselves forgetting their password at one time or another. They can use the age-old insecure process of calling the helpdesk, or opt for the far more efficient and security-minded method of using a Password Self-Service (PSS) solution. If you’ve been hiding under a rock for the last 10+ years, a PSS solution provides an environment for the user to request their password be reset, to which they are presented with several ways to identify themselves (questions, text message, etc.).
But, even with a PSS solution in place, there is still a concern around users with elevated privileges and access. The Administrator account in AD, for example, the CEO, CFO, CIO and anyone else with a C in the front of their title, and others down the corporate ladder with access to sensitive or business-critical information. The concern lies with both whether these elevated users use the same password reset requirements as normal users, and whether the passwords they use are complicated enough to thwart hash attacks.
In general, it just makes sense to require additional levels of scrutiny and security around password resets for those that have higher levels of access within in organization.
So, how should you make password resets more secure?
Whether you have a PSS solution in place, or are considering one, there are a few ways to improve security when it comes time to have a user with elevated access reset their password:
- Required Enrollment – As with all PSS solutions, there is a need for the user to enroll; they must answer some questions to provide the PSS system with enough detail that it can identify the user at the time of reset. Some PSS solutions allow for verification against an attribute in AD (a SSN value, for example). This option may not be suited well for those with elevated privileges within the organization, and requiring enrollment should be required.
- Tailored Questions – You can find most married women’s maiden names on Facebook, so that’s not a good question for regular users and certainly not good for those requiring more security. Privileged users should be required to answer questions that are of a less personal and more challenging nature.
- More Questions – if the low-level user needs to answer any two of five questions presented, privileged users should be required to answer four of the five. You want to make sure it’s really them.
- Reset Clients – Normally, the idea of having the ability to reset a password from multiple clients (usually from a web and endpoint client) is about having more options (to make it easy). But also consider that you may not want someone to be able to use, say, a web client, and to only use an endpoint to reset. This way, someone must be sitting at a domain-joined endpoint rather than just connecting via a web browser on any device.
- Use of External Authentication – Some PSS solutions integrate with external SAML 2.0-based systems (e.g. Google) to authenticate the user. Depending on the user and the external system used to authenticate, you may or may not want to use this for those with elevated access. For example, if you support every user being authenticated by Google in lieu of providing answers to the challenge questions, a malicious actor only needs to know the one password to the user’s Google account instead of the answers to the 4 challenge questions. Tread cautiously here – not saying don’t; just saying be certain the user of external authentication is either more secure, or can be used as part of the elevated criteria within your PSS environment.
- Password Complexity – Since the Windows Server 2003, password complexity has been an option for organizations to enforce the use of a mix of character types. But having a granular ability to manage password complexity (e.g. Fine-Grained Password Policies released with Windows Server 2008) is key to ensure an appropriate level of security for a given user. In some organizations, even the FGPP isn’t stringent enough, requiring an additional layer during the password reset process to ensure the most secure of passwords is created.
Password self-service increases user and IT productivity, while lowering the cost of support. It also can be a source of insecurity within the organization. By putting additional focus on elevated users to ensure it’s most definitely them at the time of reset and that the new password’s complexity is of the highest caliber, you will protect one of your organization’s front lines of security.