Introducing SSO Password Protection: Stop employees’ IdP credentials being exposed or phished

Reliably detecting phishing sites is like trying to hit a moving target, as malicious websites and domains emerge, get taken down, and re-emerge continuously across the sprawl of the web.

Existing phishing prevention solutions have tried to solve the problem by protecting the inbox, a common (but not the only) attack vector, or by chasing lists of known-bad domains.

But these approaches have two major shortcomings:

• Lack of coverage: Email-based phishing prevention tools can catch general spray-and-pray email phishing campaigns, but it only takes a small amount of tailoring to fly under their radar. The use of LLM tools to tailor phishing emails for their intended victims already makes this possible at scale. Email-based tools also fail to cover phishing attacks beyond the inbox, such as Slack and Teams phishing.

• Expired intel: Tools that rely on known-bad domains always have an incomplete picture because a domain must be reported as malicious in order to get added to a blocklist. Meanwhile, attackers can spin up new sites or host phishing pages on existing sites by exploiting vulnerabilities in them, bypassing rules around preventing visits to newly registered domains.

Using Push’s unique vantage point in the browser, we set out to attack this problem from a new angle.

Instead of trying to detect phishing websites and domains that constantly change, we can now detect (and block!) phishing attempts based on directly observing user behavior in the browser.

Our latest feature, SSO password protection, detects and blocks when a user enters their identity provider password on a webpage that does not belong to the IdP (e.g Okta, Google Workspace, Microsoft 365, etc.).

This means that even if that employee was the first person to get phished using a new attacker site, Push still detects it and blocks it.

How does it work?

Instead of detecting a phishing page based on a known-bad signature, the Push browser agent dynamically inspects user behavior and the attributes of the page itself.

The browser agent works by observing all logins and generating a salted partial hash of the user’s password, known as a fingerprint. This fingerprint is then stored locally to allow Push to perform comparisons.

To detect potential phishing attacks, the browser agent compares the observed password fingerprint to known fingerprints for identity provider passwords that already exist in local storage.

If an employee enters a known IdP password on a webpage that Push doesn’t recognize, Push blocks it.

Once you’ve discovered a malicious site, use Push’s companion feature, URL blocking, to add the domain to a blocklist and prevent your other end-users from visiting the site.

You can programmatically manage URL blocking as part of responding to an attempted phishing incident by using the Push REST API to automatically add URLs to the blocklist or to sync with other threat intelligence sources of known-bad sites.

Push administrators can configure SSO password protection in Monitor, Warn, or Block modes to first observe how often employees are re-using IdP credentials on other sites, eliminating any false positives by adding them to an ignore list, and then turning on Warn or Block to show a custom message that either provides a speedbump for users (“Are you sure this isn’t a phishing site?”) or prevents them from logging in altogether.

Supported identity providers include Okta, Microsoft 365, Google Workspace, JumpCloud, Duo and Ping Identity.

You can also get alerted via webhook when Push detects a suspected phishing event.

Learn more about how it works and the end-user experience in our help article.

But what about …

Yes, we believe MFA and conditional access policies are important parts of a defense-in-depth strategy against phishing — in addition to protecting IdP credentials directly in the browser.

Here’s why MFA and conditional access policies aren’t enough:

• MFA is not infallible and not all MFA methods are created equal. Methods such as SMS, TOTP, or even push notifications are phishable. Even if your employees are also using more phishing-resistant forms of MFA, such as WebAuthn, it’s common for accounts to use multiple MFA methods and an attacker need only target the weakest one. An attacker in possession of an SSO password also has leverage to socially engineer an authentication reset, including an MFA reset.

• It’s worryingly common for us to deploy Push and find that a customer’s conditional access policies aren’t implemented as they are designed to be. The most common reason is that admins have to create so many exceptions to allow for real-world situations that policies become complex and full of gaps.

And of course, protecting all your organization’s passwords is important. In fact, we’re currently developing this feature further so it will do just that! We focus here on IdP passwords because they’re a higher-value target for attackers — and the frequent target of recent real-world attacks.

Why IdP accounts?

IdP accounts have been targeted in several high-profile recent attacks, like those carried out by Scattered Spider against MGM resorts and in the Retool breach. You can read more about them in our identity attacks in the wild blog article.

In the cloud-first world, a compromised IdP account is like a compromised user workstation. It gives an attacker a solid initial foothold from which they can operate:

• They instantly get access to all the apps the compromised user was accessing with SSO. It’s easy to move laterally to sensitive apps or to apps where the user has admin privileges. This obviously enables an attacker to directly exfiltrate data from these apps or to use them maliciously, as in the Mandiant and SEC Twitter/X breaches.

• Assuming an attacker hasn’t initially gotten access to a privileged IdP account, they can escalate their privileges by performing SAMLjacking on any low-risk app where the user is an admin or by using apps like Slack and Teams to phish higher-privilege users.

It also protects against credential stuffing attacks

As well as protecting your users against phishing, the SSO password protection feature can prevent credential stuffing attacks succeeding against your IdP instance. How? By stopping your employees from reusing their SSO password on other apps. Push monitors the identities of thousands of employees. Around 1 in 3 of them reuse passwords across multiple accounts.

Employees know that their SSO password is one they’ll need to use a lot, and so they tend to choose one they know they will remember, because they are already using it successfully. That’s why we see higher levels of password reuse on IdP apps in particular.

Every time an SSO password is reused on another app, its exposure increases, along with the likelihood of it falling into the wrong hands. This can happen when another app experiences a breach and credentials are stolen. Or alternatively, when an attacker steals credentials in a phishing attack aimed at users of other apps where the password is being reused.

Armed with stolen credentials, an attacker can spray them across common cloud apps and see what additional accounts they can gain access to. IdP apps will be high on the list of cloud apps attackers will try because they provide much more in the way of access than a general SaaS user account.

You might be wondering if this feature can also be used to stop other password attacks such as password spraying and brute-forcing attacks. While this specific feature does not, Push’s other features do.

These include in-browser guidance that stops users from creating and using easily guessable passwords as well as Push’s ability to detect when employees are not registered for MFA (and whether the methods they are using are phishing-resistant or not).

Try it yourself

We love feedback from our users! Let us know what you think about the SSO password protection feature and its companion, URL blocking. To try it yourself, create a free account on pushsecurity.com. You can also book a demo. We’ll be happy to show you this feature, along with how we discover all the apps your employees are using and how we detect vulnerable identities.