Real-time Password Blacklist
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.
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.
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.
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.
This is a fundamental part of our solutions. Password RBL never receives a complete user credential - just a hash value.
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.
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.
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!
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.
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.