How does Push protect passwords from being reused or phished?
You can use Push to detect when an end-user has entered their SSO password or other important password on a login page that does not belong to the application, including suspected phishing sites.
Push can then monitor and report the password reuse to administrators without notifying the end-user, warn the end-user they are reusing the important password on an unauthorized or potentially malicious site, or block the end-user from logging in altogether.
You can configure the Password protection feature on the Controls page of the Push admin console. By default, this feature is in Monitor mode.
How does password protection work?
When observing logins, the Push browser extension generates a salted partial hash of the user’s password, known as a fingerprint. This fingerprint is then stored locally to allow Push to perform password comparisons. Learn more about how the extension securely observes passwords in this help article.
To detect possible phishing attempts or any password reuse, the extension compares the observed password fingerprint to known fingerprints for passwords that already exist in local storage. This means that the extension must have observed the end-user logging into their protected account at least once.
Push can detect and prevent password phishing and password reuse for any app in your inventory, including the following frequently targeted identity providers:
Okta
Microsoft 365
Google Workspace
JumpCloud
Duo
Ping Identity
SAP
IBM Security Access Manager
If an employee has entered a protected password on a webpage that does not belong to the application, Push will enforce the Password protection settings set by an administrator.
You can create a rule to apply the control to all employees, employee groups, or specific individuals, and select all apps, specific apps, or app attributes (such as Sensitivity level).

Note: If you configure one or more rules in Block mode with multiple apps, the control for Password protection will fall back to Warn mode, in order to allow employees to change their protected password.
The browser agent will also ignore flagging any scenarios in which the login page is in the monitored company domain(s), is on the Settings page under the Advanced section, or is in a private IP address space, including localhost.
You can ignore protected password reuse on known work apps by going to Advanced settings > Ignore work apps setting on the configuration slideout for this feature.
What will end-users see?
If the feature is in Monitor mode, employees will not be notified that a potential phishing event (or protected password reuse) was detected and they will not be blocked from submitting their password.
In Warn mode, employees who enter their protected password on a webpage that does not belong to the application will see a custom warning message. They must click the acknowledgement button to proceed if they are sure the site is trusted.
If the feature is in Block mode, employees who enter their protected password on a webpage that does not belong to the application will be blocked from submitting their credentials and shown a Push-hosted page with your custom block message, such as:

Markdown for styling custom message
The custom message field for the warn and block pages supports link and email syntax using markdown, but no other formatting.
Example markdown:
[Push Security](https://pushsecurity.com)
[Steph](mailto:steph@ctrlaltsecure.com)
Using wildcards
When adding URLs to your ignore list, you can use a wildcard * (star / asterisk character) to partially match website domains.
For example, *.example.com will catch any subdomains in example.com.
Note: URL match patterns do not support the syntax .example. You must use the syntax *.example.com or *.example.org if you wish to have a wildcard for subdomains.
How do I get alerted to suspected phishing events and protected password reuse?
The Push platform provides a webhook event PROTECTED_PASSWORD_ENTERED that administrators can listen for in their SIEM or other monitoring tool. Read more in our developer documentation.
You can also view and filter a rolling 7-day event view for all Push events on the Events page in the Push admin console.
If Push observes other suspicious activity that precedes the reuse of a protected password, a detection will be raised on the Detections page in the admin console. For example, if a cloned login page is detected at the same time a protected password is used, you’ll see that information grouped into a single detection.
Recommendations on using Warn and Block mode
Push recommends using this feature in Monitor mode for a few weeks before you enable Warn or Block mode. This will allow you to find any exceptions in your environment, such as sites that are configured to legitimately use protected credentials for authentication.
Monitor for webhook events during this testing period, and then add any exceptions to the Ignore specific domains list under Advanced settings on the configuration slideout for the control.

Once you have tested the feature and updated the ignore list, then you can enable Warn or Block mode.
How to create a configuration rule
You can configure this control to apply to all employees, employee groups, or just specific individuals. You can also create an exception for specific employees or employee groups who will be exempted from this control. Finally, you can enforce password protection on all apps, specific apps or app attributes.
Push recommends enforcing password protection on at least your critical applications such as your IdPs and any developer tools that store secrets.
When you enable the control, you’ll create a configuration rule that sets the Mode (Monitor, Warn, or Block), the Scope (all employees, specific groups, or specific individuals) and Apps (all apps, specific apps, or app attributes). Note that attributes are a Boolean AND operation.
To exempt an individual or group, create a rule where the Mode is set to Disable and then choose the group or people who should be exempted.
You can control the order in which rules are applied by setting the rule order on the configuration slideout. Rules are executed from the top down. Use the handlebars in the Order column to drag and reorder rules.
Option to avoid reporting URLs
If desired, you can choose not to collect URLs where the reuse of protected passwords is observed. To opt out of reporting URLs for this control, go to Advanced settings > Do not report URLs on the configuration slideout.
When toggled on, this setting prevents the Push browser agent from collecting URLs observed during protected password reuse events. On the Events page, you will still see an event for password reuse, and the URL field will be null.
You may wish to opt out of URL reporting if you want to avoid collecting this data for privacy reasons.