SECURITY AT PASSWORD RBL

Password RBL is serious about security.

Now you have probably heard that before, but Password RBL has always put security first.  So much so, that we have architected our service in a zero-trust model.  Furthermore, we strive to also be very transparent with the solutions we offer, so you can rest assured that using Password RBL is secure.  In this post, we will show you our zero-trust security model, starting with the more fundamental and work towards the more nuanced.

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 for any of your users.

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. Even using the fastest GPU-based cryptographic hash-breaking methods, it would still take many years to crack the submitted hashes.

For additional assurances, customers only send the first few characters of the hashvalues to our API.  In this mode, the API responds with all blacklisted hashes that begin with the provided prefix.  Customers perform the full hash value comparison on the client side.  Password RBL never has the complete password hash.

3. All queries are transmitted over a TLS tunnel protected with modern ciphers
Using iterative hashing with a high count (30,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.

4. All provided software source is available
Password RBL is very transparent with exactly how the password blacklisting 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!  Password Firewall is written in PowerShell, which is actually quite easy to understand.

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.

6. Zero-logging Policy
Password RBL does not track what API queries are submitted from customers. All Password RBL systems are specifically configured so they do not log any query parameters. Additionally, any remaining log information is purged on a regular and frequent basis.

7. Hardened Systems
Query API servers are firewalled so that only current customers can open direct network connections to them.  The Query KEY-API requires that all connections include a valid API key.  And all these connections are throttled/rate-limited so that even if a malicious actor becomes a customer, they cannot 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 any management sessions are started.

8. Even if Password RBL gets breached, you are 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 contact 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.

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 [partial] hash value.