9. And remember, the username is never transmitted to Password RBL

This is a fundamental part of our solutions.  Password RBL never receives a complete user credential - just a hash value.

8. Even if Password RBL gets breached, you're OK

This is opposite from what is typically the case.  Usually when a service provider is compromised, that means whatever data you've given that service provider is also compromised.  Well, this isn't the case with Password RBL.  Not only do we collect very minimal customer information, but even if our database of heavily hashed passwords were compromised, this database only contains hashes that represent passwords that are NOT being used.

Did we miss something?  Want something clarified?  Let us know!

Password RBL is serious about security.

Now you've probably heard that before, but Password RBL strives to be very transparent with the solutions we offer, so you can rest assured that using Password RBL is secure.  In this post, we'll show you our security model. We'll start with the more fundamental and work towards the more nuanced.

Wait. Passwords are sent across the Internet...

How can that be secure?

We'll show you!

A Few Words

About Security at Password rbl

Over 40,000 rounds of hashing. TLS connections. Anonymous queries.

4. All provided software source is available

Password RBL is very transparent with exactly how their password blacklist solutions work.  But, you can also verify it for yourself!  Any software provided by Password RBL is "source available" so you can read it for yourself and make sure it meets your company's security standards.  Can't read code? No problem!  You can test that the behavior of the provided software works the way we say it does.  Sign up for a free trial, install the software and capture all network traffic coming from the test system.  You'll see that it behaves exactly as described.

5. Queries are anonymous by default

While Password RBL provides Tracking IDs to customers so there is an easy way to determine how often their users are choosing bad passwords, this is not required.  By default, queries are anonymous.  There is no identifying information in your queries.  This way the API can't discern your query from another one submitted by a completely different customer.

Real-time Password Blacklist


Prevent bad passwords before they happen!

7. Hardened Systems

Password RBL API servers are firewalled so that only current customers can open direct network connections to them.  And these connections are throttled/rate-limited so that even if a malicious actor becomes a customer, they can't brute force attack Password RBL systems without being locked out.  These steps greatly reduce our attack surface.  Additionally, there is no direct path for managing core systems, and all systems trigger alerts whenever anyone logs in for management- including us!

3. All queries are transmitted over a TLS tunnel protected with modern ciphers

Using iterative hashing with a high count (over 40,000 rounds!) makes the hashes very resistant to brute force attack. Even though the hashes are so strong, Password RBL still requires all pre-hashed queries to be submitted over a TLS-encrypted tunnel using modern ciphers, preferring cipher suites that provide Perfect Forward Secrecy (PFS).  Tunnels must be TLS 1.0 (or later) - no old SSL allowed.  Go ahead, check us out on SSL Labs.

6. Zero-logging Policy

Password RBL does not track what hash values are submitted from customers.  All Password RBL systems are specifically configured so they do not log any hash values.  Additionally, any remaining log information is purged on a regular and frequent basis.

1. Usernames are never sent to Password RBL

This is very important.  Authentication systems, like those on web sites and in Microsoft Windows/Active Directory require, at least, a username and a password for successful authentication.  Usernames are never transmitted to Password RBL, so Password RBL never receives a complete credential.

2. Passwords are hashed 30,000 times BEFORE being sent to the API

Passwords that will be checked for existence in the Password RBL database are iteratively hashed on customer systems, 30,000 times, before being sent to Password RBL.  Once received, they are hashed again, this time over 10,000 times before being searched for a match in the database. Even using the fastest GPU-based cryptographic hash-breaking methods, it would still take many years to crack the submitted hashes.