

Show HN: Real time blacklist of bad passwords API - asmith-yc
https://www.passwordrbl.com

======
asmith-yc
I am the owner/operator of this subscription-based service that provides a
very easy to implement API to access a database filled with millions of bad
passwords.

Exploiting weak credentials is a very common way for "hackers" (term used
loosely here) to gain unauthorized access to accounts all across the Internet.
Many sites/apps that require login will have some form of a password policy,
but it's obvious that these password polices aren't enough. A common password
policy is something along the lines of:

* Must be at least 8 characters long * Must have at least one character from 3 of the 4 major sets (uppercase, lowercase, numbers, symbols)

But even with this password policy, the password "Password1" meets the policy
required yet it is one of the more commonly exploited passwords. Web or App
developers could try to keep a tab on all the bad passwords being used, leaked
and exploited, to include in their password policy, or they could implement a
basic policy (like above) and subscribe to Password RBL to cover the rest.

We will be launching support for Microsoft Windows Active Directory very soon.
This will open up the service to an even wider customer base. Before we go
live with this, I'd like to hear comments from the Show HN community regarding
the web site, the offering, the packages, business, marketing, etc., etc. -
anything really.

Thanks in advance.

~~~
diamondtrim
Are the subscription plans based on daily queries, or a monthly total
represented by how many per day?

For example, my company has a password policy that reminds users every 6th
Monday (we find that passwords changed on a Friday often require an IT reset
the following week because they forget, so we try to encourage updates earlier
in the week). If we tried your service, would we be penalized for a high
volume on single days?

~~~
asmith-yc
Thanks for the comment.

Currently our "queries per day" limits are an averaged value over the course
of the month. This is to allow for scenarios exactly like the one you've
mentioned.

