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.
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 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.
Maybe. Our service is designed to only allow connections from web server IP Addresses that have an active subscription to the service, and thus, the connections to the API must come from your server and not client-side processing. If your client-side code sends the password to your own server before it is sent to our API, this would work OK.
The service only allows connections from specific source IP addresses (web servers). More importantly, though, web sites that allow form submissions should always perform both client-side and server-side validation logic. Our Download Page contains a sample site that implements both. Check it out!
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.
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.
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.
We know our FAQ is verbose, but we want to provide as much information as possible so you are as comfortable as possible with the service.
We recommend reading through the entire page as it contains a lot of great information. But we also put all the questions and answers on one page so you can simply use the Find feature of your Internet browser to search for terms related to the question you have.
Let us know!
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". Outbound HTTPS is rarely blocked by firewalls, so you probably don't need to worry, but your network administrator can tell you for sure.
Reporting mode is used by some Password RBL subscribers just to 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 used for reporting purposes. The API responses should be tallied on the subscriber's side of the equation, or utilize Password RBL's TrackingID API parameter so that we can track the responses 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 typically it takes users 2-3 tries 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.
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 common for Active Directory administrators to use a 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.
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.
Just use our contact form (at the bottom of this page) and send us a note containing your new IP address(es) and we'll update our systems and let you know as soon as it is complete.
Yes, as long as the server IPs are all in one contiguous CIDR range (up to 8 IPs), this is allowed and counts as a single source, even though queries are originating from multiple servers. This is because some web sites rely on multiple servers, but support a single website/business.
Different subscription packages have a different amount of allowed queries to the API per day and/or month.. This number is the maximum number of calls to the API within that period. Every call to the API 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 daily limit has been reached, but passwords will not be checked against the blacklist API. The available pool of queries recharges slowly over the course of the next 24 hour period for daily alotments or over the course of the next month.
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. 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 inject new leaked passwords lists into the database).
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 reversing 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 brute force attacks. But being able to carry-out a man-in-the-middle attack on submissions being sent to Password RBL is really only theoretical, since all submissions are always performed over a TLS-encrypted HTTPS connection (with Perfect Forward Secrecy preferred).
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. 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.
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 the password is sent to the API. The Bcrypt and PBKDF2 algorithms are both iterative algorithms and operates in a similar manner.
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!
This is our way of describing how Password RBL anonymizes the queries sent to the service. Before your server sends in the passwords supplied by your users, they are hashed, not once but 30,000 times, using a salt and standard PBKDF2. The salt value is the same amongst all Password RBL customers, which prevents Password RBL from determining which hash values are used by which customer. Additionally, access to the API is authenticated at the network layer (by source IP address) so the API queries do not require any unique per-customer identifiable information. The term "double-blind" comes from these two concepts which result in the inability to link a specific hash submission to a specific customer. Click here to read more about how our solution is secure.
Our database of bad passwords is constantly growing as we discover more and more leaked credential lists. As of mid-2018, there are approximately 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.
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.)
Interesting. 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'd love to hear about your project. Please use the contact link at the base of the page and tell us about your ideas.
Yes. The API allows for an optional parameter that can be used to track queries. This is solely so that customers can receive metrics on how well the service is working for their site/business. This tracking feature 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. As of version 2.15, Password Firewall for Windows can log messages in the Windows Event Log when a lookup results in a database match or not.
No. You only need to subscribe for any website that will submit queries to the Password RBL API.
No. You only need to subscribe for any website that will submit queries to the Password RBL API.
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.
Password RBL supports many different payment methods. Here is a quick list..
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.
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.
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 passwdfw.ini file so your API queries also check your custom blacklist during the query.
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.
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'd like to blacklist 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.
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 these new passwords.
Real-time Password Blacklist
Licensing for Password Firewall follows the same subscription method of Password RBL and is based on the number of IPs (or blocks of 8 IPs) sending queries to Password RBL and the number of queries per day/month. Note that licenses are not based on the number of installations of Password Firewall. So, if you have three business sites, each with two Internet connections, this equates to six source IPs regardless of how many domain controllers you have deployed in your infrastructure.
Then just estimate the number of queries you expect to send each month. The easiest way to do this is to take the total number of users and multiple by two, since it typically takes end-users up to three tries to pick a good password. The subscription cost is more heavily based on expected actual use than maximum possible use.
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.
No. Read-Only Domain Controllers do not directly process password changes, so you only need to install Password Firewall on regular, writeable Domain Controllers.
No. Password Firewall only needs to be installed on Active Directory Domain Controllers.
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.
Password RBL subscriptions are based on the number of connecting IPs (or contiguous blocks of up to 8 IPs) and the number of queries per day. If your business sites have multiple Internet connections with different IP addressing, then each connection would count as a source. For example, if the main business headquarters has two Internet connections and there is a single branch office with one Internet connection, then a subscription package that allows for 3 sources would fit well.
Whether your Active Directory uses the classic single password policy or you've deployed Microsoft's newer 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, Password123, etc.).
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.
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.
Yes. Like Office365, Okta (and other cloud authentication managers) has the ability to sync 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.
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) and add the users that should have their password choices scrutinized by Password Firewall. Then open the passwdfw.ini and add this group name to the GroupFilter line.
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.
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.
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 passwdfw.ini file then you can utilize the My Metrics page at PasswordRBL.com to obtain a report and download lifetime statistics.