Self-service password reset: How the cure could introduce more security ills

Passwords certainly aren’t new -- they began in ancient civilizations so tribes and their militaries could identify their members and allies. But the management problems they present in a digital world so utterly dependent upon them are voluminous and costly. On average, business users have 87 passwords for their work-related accounts. Granting this complexity, users will inevitably need to turn to IT several times a year to resolve password lock outs. Forrester estimates that it costs an organization $70 per password reset and that large, U.S.-based enterprises allocate $1M annually for password-related support costs.

While Self-Service Password Reset (SSPR) tools -- web-based portals that enable users and administrators to reset their own passwords without IT interaction -- seem like the ideal solution, they come with risks. Today’s threat actors are exploiting every opportunity to gain credentials, and without the proper controls, SSPR solutions can be ripe for social engineering and exploitation. Artificial Intelligence is bolstering social engineering tactics while making them less detectable. Threat actors have increasingly been waging these sorts of attacks against SSPR solutions, in particular Microsoft SSPR, to gain both user and admin credentials. While it has become necessary for IT to streamline tasks in a world of burgeoning demands and complexity, any solutions deployed must be reviewed for vulnerabilities -- or the cure could be worse than the disease, leading to a catastrophic breach.

We will explore some of the potential vulnerabilities of SSPR implementations and recommend best practices for their use to help ensure greater security.

The Achilles’ Heel of SSPR

In recent months, threat actors have capitalized on weak controls to use SSPR tools for credential harvesting. SSPR tools are available publicly on the internet, leaving them more exposed to hacker manipulation. Attackers have used social engineering tactics to convince mobile carrier personnel to transfer a user’s number to a new SIM card (“SIM swap attacks”), giving them access to reset credentials on SSPR solutions. With improper controls and weak forms of multi-factor authentication (MFA), such as SMS messages and phone calls, the attacker may then be able to use multi-factor authentication to reset the user’s password in the SSPR.

If the user is a system administrator, the attacker would gain a high level of access and system control, potentially leading to a mass-destruction-level breach. In some cases, hacking SSPRs is easy, as settings only require users to answer three security questions without an MFA challenge; most if not all these types of responses can be found on the Dark Web for harvesting and easy use in the SSPR. Clearly, better controls are needed to secure user self-service.

How to Leverage SSPR Tools Safely

SSPR tools offer important efficiency advantages while reducing the risks of social engineering on Help Desk personnel -- but only if they are configured with the proper security guardrails. We recommend that users be guided to SSPR tools under the right conditions; but that administrative credentials undergo a far more rigorous process, avoiding SSPRs entirely to better safeguard their higher-level access.

User Password Resets: Best Practices

Users can be given access to SSPR tooling under the following secured conditions:

  • Software as a Service (SaaS) applications should be integrated to a single identity provider where possible to limit password spread and reduce the need for resets.
  • During new employee onboarding, user verification should include a photo for the service desk team’s reference.
  • Users should not be able to leverage weak forms of MFA, such as SMS, email, and phone calls to prevent SIM swapping and business email compromise attacks.
  • Instead, users must provide at least two forms of proof to reset their passwords, such as two forms of MFA (soft token and hard token), or secure MFA plus multiple, complex security questions.
  • Users should not be able to use self-service tools to replace devices or re-register for MFA, as this has also been abused by threat actors. They should only be allowed to reset and re-register devices (on MDM) or MFA under identity verification with the service desk and their manager.
  • Assuming device and MFA enrollment is assured, SSPR can be allowed safely by allowing access to the tool only from corporate networks, requiring security questions AND MFA challenge to reset a credential.

Administrator Password Resets: Best Practices

  • Administrators should never be allowed to leverage SSPR tooling. All administrator password resets should be done with identity and role verification with the employee’s manager and a capable IT administrator.
  • Administrators should not be allowed to leverage weak forms of MFA such as SMS, email, and phone calls.
  • Administrators should not be allowed to use public authenticators that can be backed up using their personal accounts, such as Google and Apple clouds. All restoration options for authenticators should be disabled or limited to corporate-owned and MDM-enrolled devices.
  • Service Desk personnel should not have the capability to reset MFA or passwords of administrators; other administrators of the same level should grant the reset following verification guidelines.
  • It’s important to note that some cloud solutions enable SSPR for admin accounts by default -- organizations should disable this feature and establish secure processes.

In an age where so much of our lives are in the digital domain, IT staff are as overwhelmed by demands as users are by their quickly multiplying passwords. It’s important to manage the flood efficiently, but also securely. It’s important to review all security practices in light of how threat actor tactics are changing, so the cure to the problem doesn’t introduce even more ills to the security health of the enterprise.

Image Credit: Rinchumrus2528 /

John Anthony Smith is founder and CSO of Conversant Group.

© 1998-2024 BetaNews, Inc. All Rights Reserved. Privacy Policy - Cookie Policy.