/
How does Push determine if a password is leaked or weak?
Push uses a browser extension to identify when an employee is using a leaked or weak password to log into SaaS applications.
Leaked passwords have been exposed in a data breach. Weak passwords are easily guessable.
If Push has identified a password issue, you’ll see a Recommended improvement for that employee when viewing the employee’s details in the Push admin console.
You can then use ChatOps to encourage employees with easily guessable passwords to update them. To get started messaging employees, enable the ChatOps topic for Fix password issues.
How Push identifies easily guessable passwords
To determine if a password is easily guessable, the Push browser extension checks the password against:
A list of top 10,000 weak base passwords
Number and special character variations on these weak base passwords, for example: Password1!, January2022
Variations on these weak base passwords that replace letters with numerals (1337), for example: P455w0rd.
This type of password hygiene check occurs automatically as the browser extension observes logins for your work domain. All password checks of this kind are performed locally in the browser extension, and it never sends passwords anywhere.
You can find the list of top 10,000 weak base passwords used in the Push browser extension on Github.
How Push identifies leaked passwords
To determine if a password has been exposed in a data breach, the Push browser extension queries the Have I Been Pwnd (HIBP) API. If you do not wish to check for compromised passwords, you can disable this feature in the Push admin console by going to Settings > Browser extension > Check for compromised passwords.
To preserve employee privacy and security, Push creates a hash of the passwords it collects via the browser extension and then sends the first 5 characters of the password hash to the Have I Been Pwned passwords API. The API returns all compromised password hashes that begin with those 5 characters, and then Push checks for matches. This ensures HIBP never sees the full hash that is being checked. Learn more about the process in this article.
Separately, Push also checks whether the employee username is present in the breached data using the HIBP breaches API. The password check and the username check occur separately, so Push does not know which specific account with which specific password has been compromised — only that there is a high likelihood that the employee account has been or will be compromised because both the username and the password appear in the set of breached data.
If the Push browser extension observes the use of a compromised password for an account that has known breaches, we flag it for remediation on the employee details pane of the Push admin console.