Introducing Push password enforcement — for when weak passwords are still plaguing you

It wasn’t supposed to be like this. Passwords were supposed to be dead (just ask Bill Gates).

Instead, hardworking security pros are left to sit around in community center basements drinking mediocre coffee and commiserating.

“I admit it. My users still use passwords.”

“Yeah, mine too. I’ve been telling people we’re rolling out passkeys for three years now. I’m not sure how much longer I can keep this up …”

Somber nodding all around. Hugs. A few chocolate-chip cookies on paper napkins.

This is a no-judgment zone here at Push Security. So let’s take a look at why we’re still stuck with passwords, how attackers are increasingly exploiting weak credentials to infiltrate organizations, and how Push can help you get visibility and control of all your workforce identities.

We’ll also cover how you can use Push’s latest feature, Strong password enforcement, to require that employees use strong, unique passwords. Push automatically detects when employees have weak, reused, or stolen passwords and then guides them to update their password using in-browser messaging — even on apps that don’t natively support administrative control of password posture.

3 reasons why we’re still stuck with passwords

At the risk of preaching to the choir, let’s review why we’re still stuck with passwords. 

It’s worth stating the Push perspective up front: We’re not here to push the narrative that you must completely get rid of passwords. To begin with, it’s not easy to get rid of them. Like the imaginary scene from the passwordless support group, we’ve lived the reality of this.

What we observe across our install base for the Push browser agent reinforces this reality. For the last 1 million or so logins that Push recorded, more than a quarter (26%) were password logins.

Of those password logins, 18% had a security issue with the password — reused, easily guessable, already leaked in a public breach list, or actively for sale in criminal forums.

Yet when strong, unique passwords are used in conjunction with MFA, they can provide a powerful line of defense. Indeed, in cases where onboarding an app to SSO isn’t possible (for reasons we’ll cover below), a strong, unique password plus MFA is the most pragmatic solution you can achieve.

Here’s why bad passwords persist, and why it matters.

Systemic reasons

If we zoom out, there are several systemic reasons that contribute to the persistence of password security issues:

• Self-adoption of work apps makes it extremely difficult to know all the workforce identities that exist across your environment, let alone whether they’re using a secure authentication method, or the strength or uniqueness of their password. Push’s own research shows that for an average organization, each employee has 15 identities.

• Apps optimize signups for low friction, not security. That often results in multiple authentication methods tied to any given account because local password accounts can still persist even after SSO onboarding — a phenomenon that we call ghost logins because they provide attackers with a way around a company’s enterprise SSO solution. These local accounts represent a significant risk, and most are invisible. Which brings us to …

• Many apps provide very little information to admins about the posture of accounts on that service, and even fewer offer management options to address security issues on those accounts. Some services provide no information at all about which accounts can even access a given tenant.

The impact: These systemic factors contribute to what we see many organizations grappling with: Known visibility gaps in their workforce identities, which are scattered across many more third-party apps than they imagine, and unknown account security risks for both managed and unmanaged apps.

These gaps open up a large attack surface for organizations. The 2024 Verizon DBIR found that 79% of web application compromises were the result of breached creds, and researchers at IBM reported last year that they observed a 71% year-over-year increase in cyberattacks using stolen or compromised credentials.

Technical reasons

There are also several technical reasons why bad passwords persist:

• Going passwordless is hard because it requires a large investment of time, money, and training for end-users. In environments with a mix of older and newer infrastructure, it can be challenging to get complete coverage, and employees may struggle with the transition to device-based authentication (especially when they lose their device and aren’t familiar with how to regain account access).

• Many apps do not even provide a SAML option, making it difficult to onboard every business app to SSO even once you know about them all. Last we checked, only about 30% of commonly used work apps supported SAML. Even when apps do provide the option, many charge the infamous “SSO tax,” putting the feature behind enterprise plans.

The impact: What ends up happening in many organizations is a patchwork of login methods, including passwords, passkeys, OIDC, and SAML. Looking at data from Push’s install base, we see on average around 15,000 accounts per 1,000 users, with 5,900+ outside of SSO — about 40%. 

That means more — not less — for a security and IT team to manage, often without the visibility or control they need to do so effectively.

Human reasons

Finally, there are a lot of human reasons why poor passwords persist, all of them familiar and intractable:

• Password change fatigue, resulting in weak and reused passwords — often driven by incomplete adoption of enterprise password managers or outdated password security policies that require users to rotate passwords frequently. 

• Shortcuts that busy humans take to get work done on a daily basis, including reusing passwords across personal and corporate accounts, storing passwords insecurely, and using easier-to-remember passwords over secure, complex ones.  

The impact: When there’s a large, complex, and largely invisible attack surface made up of these online corporate identities, adversaries profit. Just look at any of the major identity attacks of the past year, some of which used password-spraying and credential-stuffing techniques to compromise accounts and pivot to high-value systems and data.

Password reuse also extends the blast radius for any account takeover incident when MFA is missing — a gap that occurs more often than you may think. Typically, 37% of logins observed by Push upon initial deployment into a new customer environment do not use any form of MFA.

Why identity posture matters more in a SaaS-first world

When most work now happens via the browser on web-based applications, the stakes are even higher for preventing account takeover. That’s because the way that attacks occur in a SaaS environment is very different from traditional network attacks, and there are few effective ways to detect and respond post-account compromise.

The average SaaS attack path looks like this:

• Attackers gain control of legitimate employee accounts using stolen credentials or via password-spraying or credential-stuffing techniques.

• Attackers exfiltrate data.

• The end.

Compare that to traditional network or enterprise cloud attacks, which usually involve more complex lateral movement, privilege escalation, and defense evasion.

With limited log data and few response capabilities provided by most SaaS apps, security teams also have few good options to stop the damage of an account takeover once one has occurred. 

That’s why at Push, we advocate for “shifting left,” and preventing account takeover before it happens.

How Push helps you ensure strong passwords

There are four capabilities that security teams need in order to regain control over password security issues across their corporate accounts. Here’s how Push accomplishes each one.

1. A reliable inventory of all the apps that employees are using, including work apps and internal apps.

Push achieves this by deploying a browser agent to employee browsers that can directly observe their login activity, which feeds the data back into an admin console (or your SIEM/SOAR or other third-party system). You can enforce the installation of the agent using any MDM solution, on all major browsers.

Once the agent is activated, it begins immediately capturing employee logins and produces a real-time inventory of all your work and internal apps. Because Push observes the login directly in the browser, it can identify all the apps and accounts being used by your employees — both managed and unmanaged (shadow IT).

You can also configure Push to monitor any login to a work app, regardless of the associated email domain of the employee. This means you can monitor personal account logins to apps that are commonly used for work.

2. A way to identify the login methods an account is using, whether that’s SAML, OIDC, or password.

Again, because Push observes the login event, it can analyze the authentication method or methods in use by a given account. Push tells you which SSO accounts still have passwords associated with them, and which authentication methods are being actively used.

3. A method for analyzing whether an employee is using secure passwords on all their accounts.

Using Push, you can also check the posture of all your employee accounts. The browser agent accomplishes this by creating a salted hash of a user’s observed password and then taking the first 8 characters of that hash to store locally in the browser.

This allows Push to analyze whether the password is weak (comparing the hash to a list of 10,000 common basewords and common permutations); or reused across accounts.

Push can also identify when employee passwords have appeared in a public breach list using the Have I Been Pwned service, using a k-anonymized hash. Using similar secure methods, Push can detect when employees are sharing account credentials, whether they’re using a password manager, and which one.

Using Push’s Stolen credentials detection feature, you can also get alerted when an employee is using credentials that match those for sale in criminal forums. Push integrates with commercial threat intelligence sources to perform these matches, and you can also bring your own TI using the Push REST API to perform additional checks for in-use stolen creds. This check still happens locally in the browser, so no hashes are sent to third-party systems.

If you configure Push to also monitor for employees who are logging in to work apps using personal email addresses or any non-corporate email, Push can identify when personal accounts and work accounts are reusing passwords for the same work application.

Using the Push REST API and webhooks, you can get alerted when Push raises a security finding for an account, and when a finding is resolved.

4. The ability to solve any issues at scale, including remediating bad passwords and enforcing MFA, even on apps where the security team doesn’t have administrative control.

Finally, you can enforce self-remediation workflows using Push’s position in the browser, right where employees are working. 

Push recently released a new in-browser control to enforce strong passwords. It works by detecting when an employee has a password security issue, and then prompting them to update their password by displaying a customizable banner message when they log in to the affected account.

This control complements an existing MFA enforcement guardrail, which uses a similar workflow to prompt employees to register for MFA on apps where it’s missing.

A closer look at password enforcement

In the spirit of helping users do the right thing, we designed the password enforcement control to meet users where they are, in the most relevant context where they can fix the problem. 

Because this control is powered by the Push browser agent, security teams don’t need administrative control over every app where password accounts exist — which often isn’t practical for all the reasons we reviewed earlier. Instead, they can use Push to prompt employees to fix the issue themselves.

Here’s a closer look at how it works:

• You can enable Strong password enforcement from the tile on the Controls page of the Push admin console. 

• Using the rule editor, select whether you want to apply the control for all employees, or just specific groups or individuals, and which apps it should apply to. You can also select which types of password security issues you want to prompt users about.

• Then customize the message that employees will see. Push will then automatically display the banner based on your criteria. Where possible, Push will include a link in the banner that takes employees directly to the page in the app where they can change their password — or you can add a link yourself.

Once the password has been changed and Push verifies that the new password is strong, you’ll see the security finding cleared from the account record in the admin console and the banner will no longer display to the end-user.

Push also sends webhook events when:

• A banner is displayed

• A user clicks the link in the banner to take action

• A password is updated

• A password security finding is resolved

Where to begin

Most organizations we work with deploy the Push agent first to get an initial understanding of their attack surface and account posture issues. Then we recommend enabling the one-two punch of MFA and strong password enforcement guardrails. You can use both controls in tandem, and Push will first seek to resolve the password issues on a given account, and then prompt the user to register for MFA.

Try it yourself

If you want to learn more about how Push helps you to detect and defeat common identity attack techniques like AiTM phishing, credential stuffing, and session hijacking while improving your workforce identity posture, book some time with one of our team for a live demo.