Frequently Asked Questions

What is Password RBL?
Password RBL is a Real-Time Blacklist for Passwords. Our database contains millions of passwords that should no longer be used because they are either easily guessed or have been publicly leaked as part of the many data breaches that have occurred in recent years. Access to this database is provided in a Software-as-a-Service (SaaS) model via a RESTful Web API for web servers and apps or our Password Firewall software for Windows.

Why would I want to use Password RBL?
Hackers are gaining unauthorized access to Internet-connected businesses more and more frequently. This is because there are so many user accounts that have poor passwords set. Password RBL knows about these passwords and can prevent these passwords from being chosen in the first place.

Do I get an email when one of my passwords get leaked?
That is how a few somewhat similar services work, but that’s not how Password RBL works. While other services will notify you after your account has been hacked (hopefully very soon after the hack), Password RBL proactively prevents poor password choices which keeps hackers out in the first place.

I have vanity domains, do I need to add these to the registration form?
No. You only need to subscribe for any website that will submit queries to the Password RBL API.

How does billing work?
During the registration process, you provide your billing contact information. Every month (after the free trial) you will receive a recurring invoice for the chosen subscription package or custom quote. You can easily pay the invoice online and optionally save your credit card information to be auto-billed next month, if you like. Payments are processed by WePay. You are not providing your payment card information to Password RBL. Of course, if you prefer paying by company check, that is also an option. Simply print out the PDF invoice, follow the instructions on the payment stub and drop it in the mail.

What payment methods are avaialble?
Password RBL supports many different payment methods. Here is a quick list..

Credit Card (VISA, Mastercard or American Express)
Wire/Bank Transfer (ACH or BIC/SWIFT for international customers)
Company check via “snail-mail”

How do I change the contact email address for my subscription?
If you’d like to change or add an email address, just use the contact page and send us a note. We’ll then send a confirmation email to the original email address to verify the change.

How can I cancel my subscription?
We’re sorry to see you go and hope we served you well. To cancel your subscription, simply contact us via our web form, send an email, or call.

How do I know Password RBL isn’t just reading all my passwords?
Because it’s not possible! Passwords submitted to the Password RBL API have already been cryptographically hashed with 30,000 rounds of the industry standard PBKDF2 algorithm. Cryptographic hash functions are one-way functions that cannot be reversed or “decrypted.” This one-way property of cryptographic hashing prevents Password RBL from being able to determine original passwords from hash values being submitted. Basically, the API looks for the existence of the hash value in the database not the actual password. And, remember, any code we provide to customers is ‘source-available’ so you can go see for yourself!

How many passwords are in the database and what languages are included?
Our database of bad passwords is constantly growing as we discover more and more leaked credential lists. As of mid-2020, there are over 75 million entries in the database. These entries mostly consist of Western European Languages, such as English, Spanish, Italian, French and German. However, other languages are included and are typically sourced through honeypot services and hacker tool analysis.

After I subscribe, can I use the service to scan all my existing user passwords?
Unfortunately, no. The service is only a real-time query and can only accept passwords hashed with the salt and algorithms specified in the API. But your users’ passwords should already be uniquely salted and hashed in a different manner. (And if you’re storing passwords properly, you should not be able to decrypt passwords.)

Can I subscribe to the service if I send queries from an application rather than a web server?
Yes. Although, the service was originally designed with Active Directory and web servers in mind, but technologically, it will work if you can perform HTTPS GET requests and compute a PBKDF2 (or alternatively, a SHA256) hash. We would love to hear about your project. Please use the contact link at the base of the page and tell us about your ideas.

Can I receive a report that shows how many of my users are choosing bad passwords?
Yes. The API allows for an optional parameter that can be used to count queries. This is solely so that customers can receive metrics on how well the service is working for their site/business. This is known as a Tracking ID but it only counts positive or negative responses. It does not log the submitted values. This Tracking ID is completely optional so that customers who still wish for their queries to remain anonymous can continue to send anonymous queries to the service. Head over to the My Metrics page to get a custom report.

If you wish to continue sending anonymous queries, then you’ll need to keep track of query results on your side of the connection in order to determine how many submissions to the API occur and how many times a match is returned.  Password Firewall for Windows logs messages in the Windows Event Log when a lookup results in a database match or not.

What is the difference between the Password RBL blacklist and the Pwned Passwords blacklist?
Password RBL has been developing its highly-curated blacklist since 2013. We maintain and update this blacklist for customers of Password RBL. Pwned Passwords blacklist is maintained by Troy Hunt. It is a newer blacklist, and contains more permutations than Password RBL’s blacklist, but it is not as curated. It is essentially the largest blacklist possible, but there are many password hashes that have only been found in leaks one time. However, each hash in the Pwned Passwords blacklist contains a count of how many times that password has been found, so you can “curate” this large list on your own by requiring a password hash’s count to cross a certain threshold before it is considered “bad enough” to block. Password RBL allows you to query both blacklists simultaneously for maximum protection and you can choose your own threshold, too.

Do I need to open any ports on my firewall to use Password RBL service? If so, which ones?
You probably do not need to change your firewall configuration. Queries sent to the Password RBL API are sent via standard HTTPS (TCP/IP port 443) to “api.passwordrbl.com or key-api.passwordrbl.com”. Outbound HTTPS is rarely blocked by firewalls, so you probably do not need to worry, but your network administrator can tell you for sure.

What is Reporting-Only Mode?
Reporting mode is used by some Password RBL subscribers to only monitor the quality of passwords chosen by their employees/users. In this implementation, no action is taken on the subscribing website/AD if the password chosen by the end-user is listed in the Password RBL database. Instead, the API responses are just logged for reporting purposes. The API responses should be tallied on the subscriber’s side, or customers can utilize Password RBL’s TrackingID API parameter so that we can count the matches for you. If you choose the latter (and easier) method, then head over to the My Metrics page to run reports based on your Password RBL assigned TrackingIDs. Do note that when using Reporting-Only Mode, you will see a lower hit-percentage than when using the API in normal mode because it sometimes takes users more than once to pick a non-listed password, but in Reporting-Only mode, there is only one query to the API regardless if the chosen password is listed or not.

Why would I want to use than one Tracking ID?
In short, for more granular reporting. For example, for one subscription fee, you can send queries to Password RBL from multiple different systems. Each of these systems could use their own Tracking ID so you could get system-specific metrics on password choices between say, your public eCommerce site, your internal Intranet site, and your Active Directory. It’s also somewhat common for Active Directory administrators to use a separate Tracking ID for all domain controllers at each business site. They can use the reporting data to determine which site(s) need more password training.

Does Password RBL provide any implementation assistance?
Currently we do not. Every subscribing site is different, and no one will know it as well as the website operator. But, while we don’t help you with your specific website, we do provide sample code, including a few working sites, so you can see how to add Password RBL to your site. Head over to our Downloads page to download our code examples.

We’ve changed web hosts and/or ISPs, how can I update the sources of my queries?
Just use our contact form (at the bottom of this page) and send us a note containing your new IP address(es) and we will update our systems and let you know as soon as it is complete.

How are the “Queries per Month” counted and what happens if I go over the limit?
Different subscription packages have a different amount of allowed queries to the API per month.. This number is the maximum number of calls to the API within a 30 days moving period. Every password check counts as a query.

This concept is best explained by example. If it takes one of your end-users three tries to pick a good password, then this counts as 3 queries. Once you have reached your limit, no more connections to the API are allowed. By default, Password Firewall will allow password change events to occur if your quota has been reached (you can change this behavior if you prefer).

Where do I place the code on my website to use the Password RBL API?
You place the code in the server-side validation logic associated with the HTML form submission for new user account creation and/or existing user account password changes or resets. For additional security, you can query Password RBL every time a user logs in, and if their password is listed in the API, then you could suggest or force them to change their password.

How does the service block logins on my website?
Actually, the Password RBL API service does not block logins on your website. The API only tells your server if the submitted password exists in our growing database of known bad passwords. You decide what to do with this information. You can choose to deny the use of this password on your website and have your user choose a new password, or you could warn your user and ask if they’d like to choose a new password. Alternatively, you could also use the API in reporting-only mode.

What is the difference between Query and Prefix-Query method calls?
Query is easier to use and lets you utilize all features of the API in a single API call. Query responds with a yes or no answer to the existence of the provided hashvalue in our blacklisted passwords database. Prefix-Query is more complex to use, but since only a portion (prefix) of the computed hashvalue is provided to the API, this method provides an additional assurance that there is absolutely no way for Password RBL to determine the plaintext of the end-user’s password choice. Prefix-Query responds with a list of all hash values in our database that begin with the provided prefix value (5 characters). Read more about both in our API Guide available on our Downloads page.

How is Password Firewall for Windows licensed?
Licensing for Password Firewall follows the same subscription method of Password RBL and based upon the number of AD Users.  Note that licenses are not based on the number of installations of Password Firewall. So, if you have three business sites, each with two Domain Controllers, this equates to six installations of Password Firewall but no additional cost.

Where do I install Password Firewall in my network?
Password Firewall needs to be installed on every Active Directory Domain Controller to ensure complete protection from bad passwords. Payment to utilize Password Firewall follows the Password RBL subscription model and is not licensed per installation so you are not paying for each installation. The installation is lightweight, quick and easy but does require the server(s) to be restarted, so plan accordingly.

Do I install Password Firewall on Read-Only Domain Controllers (RODC)?
No. Read-Only Domain Controllers do not directly process password changes, so you only need to install Password Firewall on regular, writeable Domain Controllers.

Do I have to install Password Firewall on domain-joined workstations?
No. Password Firewall only needs to be installed on Active Directory Domain Controllers.

Do my end-users have to do anything different when changing their network password?
No. This is one of the greatest features of Password Firewall. End-users and Administrators use the normal built-in methods for updating Active Directory passwords. There is nothing new to learn and users/helpdesk employees don’t need to do anything differently.

I prefer to use IP-based authorization.  What IP addresses do I need to provide to Password RBL if I have multiple Internet Connections?
If you prefer to use IP-based account authorization (instead of supplying your API key to Password Firewall), then you will need to provide the Public IP addresses assigned to any of your business sites that have Domain Controllers running.

If your business sites have multiple Internet connections with different IP addressing, then you should provide the IP addressing for each connection.  For example, if the main business headquarters has two Internet connections and there is a single branch office with just one Internet connection, then you should be providing 3 [groups of] IP addresses.

How does Password Firewall fit in with Windows Password Policy?
Whether your Active Directory uses the classic single password policy or you’ve deployed Microsoft’s Fine-Grained Password Policies, Password Firewall operates as an extension to the existing Windows password policy. So whatever portions of the built-in Password Policies you choose to implement, Password Firewall will also apply. For maximum security, you should enable every built-in policy and use Password Firewall to block all the passwords that are bad but are not captured by the built-in policy (i.e., Password1, Monkey1234, etc.).

My Domain Controllers don’t have direct Internet access. Will Password Firewall work through a proxy?
We understand that many organizations decide to prevent direct Internet access from their domain controllers as a security precaution. Password Firewall has options for sending queries to our API via your explicit proxy. Password Firewall is also confirmed to work with a properly implemented transparent SSL Proxy. These types of “man-in-the-middle” SSL Proxies are common features in business firewalls (Fortigate, Sonicwall, etc.) or are implemented as standalone products (Websense, Barracuda, etc.). Technically, as long as the SSL Proxy’s CA certificate is in the Domain Controller’s System-level Trusted Certificate Authorities store, then the connection to the blacklist API will function.

Is Password Firewall compatible with Office 365?
Yes. If your Office365 account is setup for Directory Sync, you have the option to sync passwords with your on-premise Active Directory via a process known as Password Write-Back. This allows your end-users to change their password while using Office365 resources. The password write-back process still subjects new password choices to your on-premise Active Directory password policy. Since Password Firewall operates as an extension to your AD Password Policy, password changes made via Office365 will also be scrutinized against our blacklisting service.

Is Password Firewall compatible with Okta or other cloud authentication managers?
Yes. Like Office365, Okta (and other cloud authentication managers) has the ability to push down password changes made via Okta to your on-premise Active Directory. Okta uses an “AD Agent” bridge service to facilitate this process. When a user changes their password at Okta, the AD Agent attempts to set the same password on their AD account. If this password does not meet your on-premise AD password policy, the password change fails. Password Firewall operates as an extension to AD Password Policies and thus, password changes made via Okta will also be scrutinized against our blacklisting service.

Can I limit which users are affected by Password Firewall?
Yes. By default, all user password changes are processed by Password Firewall, but you can control this based on Active Directory group membership. Simply create an AD security group (one per domain).  Then re-run the Password Firewall setup and add this group name when prompted to configure the GroupFilter.  This group can either contain users who should be scrutinized by Password Firewall (Inclusion type group) or users who should be exempted from password scrutiny (exclusion type group).

Why is Password Firewall programmed in PowerShell?
Some applications have pre-requisites that make installation and support more complex. PowerShell is already built-in to all Windows Servers and has all the functionality needed to support Password Firewall, so utilizing PowerShell keeps the Password Firewall client software lightweight and easy to deploy. Furthermore, PowerShell scripting is a humanly readable format that is easy to understand (even for non-programmers) and any legitimate security-based software solution should be able to show its source code without impacting the security of the solution.

Can I change the passwdfw.ps1 file?
Password RBL will not be able to support any changes. If you do choose to augment the script file, exercise extreme caution. The passwdfw.ps1 script is executed with SYSTEM level permissions so it is very important to follow all programming best practices so you don’t expose your system to any security risks. Be aware that re-installations and upgrades using the Password Firewall Easy Installer will overwrite any changes you’ve made to the passwdfw.ps1 script.

How do I get a report of how many bad passwords are being blocked?
The easiest way to do this is to use the tracking IDs assigned to your Password RBL account. If you add your specific tracking ID to the Password Firewall configuration, then you can utilize the My Metrics page to obtain a report and download lifetime statistics.

I’m interested in using a custom password blacklist, so where do I start.. how does it work?
Using the custom blacklist feature of Password Firewall or the Password RBL API is easy! First you need to make a list of the passwords you want to add to your blacklist. Then, the easiest way to add these passwords to your custom blacklist is to use our provided custom blacklist management utility (written in PowerShell so you’ll need a Windows computer). Then just make sure you are using Password Firewall v2.0 or later and you’ve added your custom blacklist ID to the Password Firewall configuration so your queries also check your custom blacklist during the query process.

Can Password RBL see the passwords I add to my blacklist?
No. This is because before the passwords get sent to the Password RBL API, they are heavily hashed – just like how the queries to Password RBL work. So, this means you are just sending Password RBL the cryptographic hashes of the passwords being chosen. There is no feasible way for anyone, including Password RBL, to reverse these hashes.  Hashes are one-way functions.

Can I use wildcards when building my custom blacklist?
No. The provided custom blacklist management utility and accompanying API do not allow wildcards. This is because the custom blacklist feature of Password RBL is implemented the same way the shared blacklist is implemented, so that even Password RBL cannot determine what passwords are in your custom blacklist. You just need to create an input file that has each password permutation you would like to block – one per line. The custom blacklist management utility then takes each password, hashes it before adding it into your custom blacklist. The provided documentation has some suggestions for creating common permutations of bad passwords.

I ran the Custom Blacklist Management utility. I get the response “unnecessary.” What does this mean?
This is not an error. It just means that it was unnecessary to add or delete this entry from your custom blacklist because it either already existed (in the case of “add”) or it wasn’t in the custom blacklist (in the case of “delete”). There is no penalty for submitting unnecessary queries, so you can disregard these messages. However, if you have a large blacklist and are just adding a few entries, it will be faster if you perform the adds using just a list of the new passwords rather than a complete list that includes passwords that you know are already in the custom blacklist.

Sure Password RBL helps prevent data leaks, but what if Password RBL gets breached? Is my company at risk if the Password RBL database is leaked?
No. Password RBL was designed with security at the forefront. We take all possible precautions to protect our systems from known attacks and theoretical ones.  On top of that, if the Password RBL API systems were compromised and the database were leaked, this would still pose no security threat to customers. This is because we are not storing the passwords that your customers are using, we are storing millions of password hashes that they are not using. If an unauthorized party did obtain the Password RBL database, this would not help them at all. And furthermore, all passwords added to the database are always stored as hashes, and the original cleartext passwords are not stored in any online systems (Password RBL maintains separate, offline, systems we use to curate and inject new leaked passwords lists into the curated database).

The API Guide specifies I can use PBKDF2 or SHA256 hash algorithms. Which should I use?
The recommended, and default, choice is PBKKDF2. This is because it uses many thousands of rounds of hashing to slow down any theoretical, future brute force attempts at breaking the hash values. SHA256 is a very compatible algorithm that can be calculated by most all systems or software libraries. It is included for this very reason, but only performs one round of hashing before being sent to the API. So it is less resilient to theoretical future brute force attacks.  If you are using the Prefix-Query API method, then either algorithm is fine since you are never sending the complete hash off your system.  Password Firewall for Windows uses the Prefix-Query method.

You mention that the salt values used are always the same. Shouldn’t salts always be different?
When protecting user credentials, yes, salt values should always be unique. This prevents two accounts that have chosen the same password from having the same hash value in your database.  This is especially important if a credential database is leaked to unauthorized parties. But Password RBL is not protecting user credentials, and furthermore, we need the same input to always result in the same hash output so we can match the value in our database without knowing the original cleartext password.

Why doesn’t the service use bcrypt to protect the hashed passwords in the database?
A password-based key derivation function (PBKDF), like bcrypt, should always be used to protect credentials used to access an account. Bcrypt was one of the first PBKDF functions. Password RBL uses a more recent and very popular/compatible function called PBKDF2 with 30,000 rounds of hashing – before communicating with the API. The Bcrypt and PBKDF2 algorithms are both iterative algorithms and operate in a similar manner.